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UTILIZATION  OF  HUMAN  RESOURCES  DATA  IN  BATTLEFIELD  AUTOMATED  SYSTEMS 
BRIEF 


—J  This  volume  reports  on  how  well  human  resources  data  (HRDThave  been 
used  in  the  development  of  US  Army  command,  control,  communications, 
and  intelligence  (C^I)  systems.  It  makes  recommendations  for  increas¬ 
ing  the  utility  of  such  data.  The  findings  and  recommendations  re¬ 
ported  here  come  from  a  study  carried  out  with  the  following  objectives: 

)  •'  To  examine  the  Army  system  development  cycle  from  the 
proponent's  point  of  view. 

2)To  identify  points  within  the  cycle  where  human  resources 
data  would  have  a  pronounced  impact  on  operational  con¬ 
cepts,  system  definition  requirements,  training  require¬ 
ments,  doctrine  development,  and  other  aspects  of  the 
proponent's  role. 

j 

-  eyTo  identify  ways  of  improving  the  development  and  use  of 
human  resources  data.  cy ^ 

J 

w To  identify  the  technological  gaps  in  the  problem  of 
incorporating  human  resource  data  in  the  system  develop¬ 
ment  cycle. 


The  use  of  human  resources  data  was  studied  in  the  development  cycles 
of  two  C3l  systems:  the  Tactical  Operations  System  (TOS)  and  the 
Stand-Off  Target  Acquisition  System  (SOTAS).  The  XM1  Abrams  Main 
Battle  tank  was  also  examined  in  order  to  provide  a  comparison  between 
weapon  system  development  and  C3i  system  development  ■ 

Finding:  l'  '  )  M. 
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The  three  systems  examined  were  found  to  exhibit  widely  different 
results  in  the  effective  use  of  human  resources  data  in  the  system 
development.  In  the  TOS  program,  human  resource  issues  were  assigned 
a  low  priority  relative  to  other  problems,  so  that  there  never  existed 
a  focal  point  in  the  system  development  team  for  addressing  such  issues. 
By  contrast,  the  SOTAS  program  set  high  management  priority  on  human 
resource  issues  at  the  very  outset  and  retained  as  the  focal  point 
for  such  issues  a  Deputy  Project  Manager  (DPM),  assisted  by  a  team  of 
behavioral  scientists.  The  SOTAS  program  was  able  to  resolve  certain 
difficult  personnel  and  training  problems  because  these  problems 
received  early  attention  in  the  development  cycle.  The  third  program, 
that  of  the  XMI  tank,  has  had  mixed  success  in  using  human  resources 
data  in  its  development.  Because  there  was  considerable  management 


interest  in  the  human  factors  engineering  of  tank  operations,  this 
area  represented  highly  effective  use  of  HRD.  But  in  three  other 
areas:  organizational  maintenance,  DS/GS  maintenance,  and  logistical 
support,  delayed  management  attention  has  resulted  in  less  than  effec¬ 
tive  application  of  human  resources  data. 

Throughout  its  23  years  under  development,  the  70S  program  has  not  had 
any  human  factors  personnel  or  applied  psychologists  familiar  with 
automated  data  processing  systems  on  the  system  design  team.  Human 
resource  issues  were  largely  excluded  from  consideration  until  it 
came  time  to  evaluate  the  system.  Human  resource  data  has  not  been 
adequately  incorporated  in  the  system  development  notwithstanding 
the  fact  that  ARI  (and  its  predecessor  BESRL)  has  provided  support 
in  terms  of  human  factors  research.  Starting  in  1966,  BESRL  provided 
support  in  both  the  field  tests  and  laboratory  approaches  to  TOS 
development.  Starting  in  1967  -  and  continuing  through  1977  -  ARI 
conducted  extensive  laboratory  analysis  of  tactical  information  proces¬ 
sing  under  the  Simulated  Tactical  Operations  System  (SIMTOS)  program. 
Starting  in  1970,  ARI  also  conducted  a  number  of  research  projects 
on  the  tactical  data  entry  process.  These  research  results  have  not 
been  effectively  used  in  the  TOS  program.  This  is  largely  because 
there  has  been  no  focal  point  in  the  program  for  human  resources 
data. 

The  SOTAS  program,  on  the  other  hand,  represents  very  effective  em¬ 
ployment  of  human  resources  data.  It  has  incorporated  human  resource 
issues  since  the  initial  milestone  review.  The  Project  Manager  (PM) 
recognized  early  that  several  complex  human  engineering  problems  had 
to  be  solved  before  SOTAS  could  become  an  operationally  effective 
system.  The  SOTAS  development  program  began  with,  and  continues 
today  with,  a  project  management  structure  that  effectively  addresses 
the  human  factors  and  human  engineering  issues  in  the  C3I  system. 
Because  the  program  represents  a  successful  example  of  the  utilization 
of  HRD,  the  details  of  what  was  done  and  when  it  was  done  provide  a 
valuable  case  study. 

The  XM1  Abrams  Tank  Program  was  reviewed  in  order  to  compare  weapon 
system  development  with  C^I  system  development.  This  program  exhibits 
a  spotty  picture  regarding  the  use  of  human  resource  issues.  High 
management  priority  was  given  to  the  human  factors  engineering  inso¬ 
far  as  tank  operations  were  concerned,  but  there  was  delayed  recogni¬ 
tion  of  the  personnel  and  training  requirements  for  organizational 
maintenance,  DS/GS  maintenance  and  logistical  support. 

All  three  case  studies  suggest  that  the  effective  use  of  human  re¬ 
sources  data  in  the  system  development  cycle  is  dependent  on  the 
amount  of  management  emphasis  on  these  issues  and  the  early  recogni¬ 
tion  of  all  the  specific  human  factors  problems  in  the  system. 


Conclusions  and  Recommendations: 


The  central  conclusion  is  that  the  key  to  the  successful  use  of 
human  resource  data  in  system  development  is  the  early  recognition 
by  the  project  management  of  the  relevant  human  factors  problems 
and  human  resource  requirements  and  then  the  establishment  of  a 
management  structure  to  provide  a  focal  point  for  these  issues.  In 
order  to  do  this  management  must  be  shown  the  direct  relevance  of 
human  resource  issues  on  system  effectiveness.  This  means  that  a 
quantitative  link  must  be  developed  between  human  resources  and 
battle  outcome. 

The  following  two  recommendations  for  further  research  constitute 
a  program  to  establish  the  quantitative  link: 

•  Development  of  a  Human  Resources  Data  Base.  This  data 
base  will  relate  human  aptitudes  and  basic  skills  to 
task  performance,  training  requirements,  and  personnel 
requirements. 

e  Development  of  Model s  relating  Human  Performance  on 
Battle  Outcome.  These  models will  provide  the  tool s 
for  showing  the  quantitative  link  between  human  re¬ 
sources  and  system  effectiveness. 


RE:  Classified  References,  Distribution 
Unlimited 

No  change  in  the  distribution  statement. 
Per  Mr.  Douglas  Edwards,  Army  Research 
Institute  for  the  Behavioral  and  Social 
Sciences 


Codes- 

■l/jxr 


*  ff--  *  pjV-Jfc  > 1 ,  TIf  *> "iv V «/  fl  Ji  | 


SECTION 


APPENDICES 


TABLE  OF  CONTENTS 


TABLE  OF  CONTENTS 
LIST  OF  FIGURES 
LIST  OF  TABLES 

INTRODUCTION 

1.1  Problem  Statement 

1.2  Army  Development  Cycle 

1.3  Human  Resources  Guidance  in  the  Development 

Cycle 

HUMAN  RESOURCES  DATA  UTILIZATION:  CASE  STUDIES 
OF  TOS,  SOTAS,  AND  XM1 

2.1  Tactical  Operations  System 

2.2  Stand-Off  Target  Acquisition  System 

2.3  XM1  Abrams  Tank  System 

APPLICATION  OF  HUMAN  RESOURCES  DATA  IN  SYSTEM 
DEVELOPMENT 

3.1  Definition  of  Human  Resources  Data 

3.2  Manpower  and  Personnel 

3.3  Biomedical 

3.4  Maintenance 

3.5  Training 

3.6  Human  Factors  Test  and  Evaluation 

3.7  System  Integration 

3.8  Conclusions 

SUMMARY  AND  RECOMMENDATIONS 

4.1  Effective  Use  of  HRD  in  Systems  Development 

4.2  Generation  of  Critical  HRD  in  System 

Development 

4.3  Technological  Gaps  in  Human  Resource  Data 

4.4  Recommendations  for  Further  Research 


dtdi  TfiftRAPHY 

ARMY  MAJOR  SYSTEM  ACQUISITION 
LIST  OF  ACRONYMS 


v>VW!LV.>\vv.;a;.v 


i 


LIST  OF  FIGURES 


IGURE  P 


1-1  MATERIEL  ACQUISITION  PROCESS  FOR  MAJOR  SYSTEMS  1 

1- 2  PERSONNEL  CONSIDERATIONS  IN  SYSTEM  EFFECTIVENESS  1 

2- 1  DIVISION  TOS  SYSTEM  CONFIGURATION  WITHIN  A 

DIVISION  2 

2-2  SOTAS  PRIMARY  GROUND  STATION  VAN  LAYOUT  2 

2-3  SOTAS  INFORMATION  TRANSFER  MODEL  2 

2-4  SOTAS  HUMAN  FACTORS  PROCESS  2 

2-5  SOTAS  HUMAN  FACTORS  FIVE  YEAR  EMPHASIS  2 

2- 6  TOPICS  CONSIDERED  BY  THE  HEL/MRDC  HFE  ANALYSIS  2 

3- 1  MAINTENANCE  MANPOWER  MODELING  FLOW  DIAGRAM  3 

3-2  INSTRUCTIONAL  SYSTEM  DEVELOPMENT  FLOW  DIAGRAM  3 

3-3  IMPACTS  OF  EARLY  DEVELOPMENT  AREAS  EFFECTING 

TRAINING  3 

3-4  BEHAVIORAL  OBJECTIVE  FORMAT  TAKEN  FROM  SAT  REPORTS  3 

3-5  THE  FIDELITY  OF  VARIOUS  TEST  TECHNIQUES  AND  THE 

FLEXIBILITY  WITH  WHICH  THEY  MAY  BE  APPLIED  3 

B-l  ARMY  DEVELOPMENT  CYCLE  FOR  MAJOR  SYSTEMS  B 

B-2  OPERATIONAL  TEST  AND  EVALUATION  CYCLE  B 

B-3  OPERATIONAL  TEST  AND  EVALUATION  PROCESS  B 

B-4  LIFE  CYCLE  SYSTEM  MANAGEMENT  MODEL  B 


r waww  ’r’rv'K  wwwwwm wjmwwwwiw.iTw»wawi iwwmvjrTOa; 


LIST  OF  TABLES 


REQUIRED  DOCUMENTATION  FOR  MAJOR  SYSTEM 

ACQUISITION  2-2 

A  HIGHLY  ABBREVIATED  LIST  OF  SOME  OF  THE 

RELATIVE  ADVANTAGES  AND  DISADVANTAGES  OF  MEN  3-10 

AND  MACHINE 

LIST  AND  DEFINITION  OF  HUMAN  RESOURCES  DATA  INPUTS  3-11 

NEW  APTITUDE  AREA  COMPOSITES  3-15 

SUMMARY  OF  LITERATURE  CONCERNING  PERFORMANCE 
DETERIORATION  AS  THE  RESULT  OF  ENVIRONMENTAL  3-18 

CONDITIONS 

HUMAN  RESOURCE  TECHNOLOGY  DATA  3-36 

AVAILABLE  HRD  METHODOLOGIES  3-41 


SECTION  I 
INTRODUCTION 


This  final  report  reviews  the  utilization  of  human  resources 
data  (HRD)  in  the  development  of  US-  Army  command,  control, 
communications,  and  intelligence  ( C5 1 )  systems  and  makes 
recommendations  for  increasing  the  utility  of  such  data.  The  study 
was  conducted  under  research  contract  MDA903-79-C-0695,  funded  by  the 
US  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences 
(ARI) .  The  objectives  of  the  study  were  to  examine  the  Army  system 
development  cycle  from  the  point  of  view  of  the  system  proponent;  to 
identify  points  within  the  cycle  where  human  resources  data  would  have 
the  most  impact  on  operational  concepts,  system  definition 
requirements,  training  requirements,  doctrine  development,  and  other 
aspects  of  the  proponent's  role;  to  identify  available  methods, 
procedures,  and  practices  for  providing  and  using  human  resources 
data;  and  to  identify  technological  gaps  requiring  research  and 
development  to  support  the  use  of  human  resources  data  by  Army  systems 
proponents . 

Efforts  were  directed  at  identifying  points  in  the  system 
development  cycle  for  the  Tactical  Operations  System  (TOS)  and  the 
Stand-Off  Target  Acquisition  System  (SOTAS)  when  the  system  proponent 
used  or  could  have  used  human  resources  data  and  associated 
methods.  The  XM1  Abrams  Main  Battle  Tank  .was  examined  to  compare  and 
contrast  weapon  system  development  with  CJI  system  development.  The 
emphasis  of  this  report  is  on  the  types  of  data  or  analyses  used 
successfully  or,  if  not  used,  which  might  have  been  used  beneficially. 

Acronyms  are  used  frequently  throughout  the  report  and  are 
fully  identified  the  first  time  they  are  used.  A  list  of  these 
acronyms  and  other  abbreviations  is  presented  in  Appendix  C. 

1.1  PROBLEM  STATEMENT 

In  its  search  for  greater  combat  effectiveness  and  increased 
combat  capability,  the  US  Army  has  made  significant  strides  in 
harnessing  technology  to  improve  mobility,  firepower,  communications, 
logistic  support,  and  intelligence  collection.  This  effort  has 
produced  new  hardware,  new  system  designs,  new  organizational  and 
operational  concepts,  and  new  doctrine  for  the  employment  of 
functional  components  of  the  tactical  force.  These  developments  have 


been  extended  to  weapon  systems  which  include  automatic  data 
processing  in  the  closing  of  the  target  engagement  loop.  There  has 
been,  however,  little  corresponding  improvement  in  the  development  of 
automated  battlefield  systems  of  the  decision-aiding  variety,  such  as 
TOS.  Despite  more  than  25  years  of  applying  extensive  technological 
resources  to  this  problem,  there  has  been  a  fundamental  lack  of 
success  in  fielding  an  automated  tactical  command  and  control  (Cz) 
system  in  the  Army  or  any  other  service. 

It  has  long  been  recognized  that  the  development  of  systems 
must  take  into  account  the  characteristics  of  the  expected  user.  As  a 
result,  an  extensive  body  of  knowledge  has  been  accumulated  on  the 
description,  attributes,  and  skills  of  users.  Much  of  this  k/iowledqe 
bas  Jjeep  incorporated  into  various  "human  factors"  handbooks  1 
’  *  and  subsequently  utilized  by  system  designers  in  hardware 

design  and  development.  However,  the  emphesis  during  the  development 
of  automated  battlefield  systems  has  been  narrowly  focused  on 
equipment  rather  than  on  operator  performance. 

Various  explanations  can  be  offered  for  this  relatively 
narrow  focus,  but  all  eventually  lead  to  the  conclusion  that  existing 
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handbooks  or  guidelines  generally  have  been  unavailable  to  or 
uninterpretable  by  the  typical  automated  system  designer. 
Accordingly,  the  designer  has  been  without  adequate  information  to 
address  other  aspects  of  human  resources  and  their  interaction  with 
the  system.  For  example,  in  well-researched  areas,  such  as  keyboard 
design  and  certain  physical  properties  of  displays,  handbooks  *  *  * 

provide  the  system  designer  detailed  guidelines  on  human  attributes 
to  design  consoles  or  other  interface  devices  and,  in  some  cases,  to 
select  appropriate  off-the-shelf  input/output  devices.  However, 
available  design  guidelines  become  sparse,  contradictory,  or 
nonexistent  when  considering  design  trade-offs  that  must  be  made 
concerning  more  central  issues  such  as  training,  task  allocation  among 
users  and  machines,  user  information  requirements,  decision  aids,  and 
interactive  dialogue  techniques.  So  it  is  not  surprising  that  even 
though  the  designer  may  recognize  that  many  design  decisions  have 
human  resources  overtones,  he  will  narrowly  focus  on  the  man/machine 
interface--not  on  determining  the  functional  role  of  humans  within  the 
context  of  the  total  system. 

The  implication  is  that  human  factors  analysis  has  been  used 
primarily  to  determine  the  "how"  of  the  interface  and  not  to  answer 
the  more  fundamental  questions  of  "who,"  "where,"  and  "why"  during 
system  design.  Answers  to  the  latter  questions  would  allow  the  system 
designer  to  integrate  considerations  for  operators  and  machines 
simultaneously,  rather  than  to  design  machines  and  then  attempt  to  fit 
operators  into  the  system.  Accordingly,  it  is  imperative  that  the 
system  designer  incorporate  answers  to  these  questions  and  their 
associated  personnel  impacts  if  the  Army  is  to  achieve  any  significant 
progress  in  the  development  of  automated  battlefield  systems.  In 
order  to  accomplish  this  goal,  systems  designers  must  be  given 
adequate  guidelines  as  to  when  and  how  to  consider  these  questions  to 
effectively  use  human  resources  data  in  the  system  development  cycle. 


E,  J.  McCormick,  Human  Engineering.  New  York:  McGraw-Hill,  1957. 

C.  T.  Morgan,  J.  S.  Cook,  A.  Chapanis,  and  M.  W.  Lund,  Human 
Engineering  Guide  to  Equipment  Design.  New  York:  McGraw-Hill , 


C.  F.  Schmid,  Handbook  of  Graphic  Presentation.  New  York:  Ronald 
Press,  1954. 

Tufts  College,  Institute  of  Applied  Experimental  Psychology, 
Handbook  of  Human  Engineering  Data  (2nd  Ed.).  Office  of  Naval 
Research,  Special  Devices  Center,  NavExos  P-643,  Technical  Report 
No.  SDC  199-1-2,  1952. 
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Based  on  the  foregoing,  the  research  problem  here  is  to 
examine  the  Army  system  development  cycle  (as  it  relates  to  CJI 
systems)  from  the  point  of  view  of  the  system  proponent  to  identify: 


t  Points  within  the  cycle  where  human  resources  data 
would  have  the  greatest  impact  on  operational 
concepts,  system  definition  requirements,  training 
requirements,  doctrine  development,  and  other  aspects 
of  the  proponent's  role — with  special  emphasis  on 
improving  the  determination  of  an  optimal  division  of 
labor  among  users  and  machines  in  decision-aiding 
systems 

•  Available  methods,  procedures,  and  practices  for 
providing  and  using  human  resources  data--to 
facilitate  trade-offs  among  manpower/training/hard¬ 
ware/software/system  design  considerations 

•  Potential  improvements  in  the  use  of  human  resources 
data  in  the  development  of  C^I  systems 

•  Technological  gaps  requiring  research  and  development 
to  enhance  the  utilization  of  human  resources  data  by 
Army  system  proponents. 


Before  proceeding  further,  it  will  be  useful  to  review  briefly  the 
Army  major  system  development  cycle  and  to  discuss  the  current 
regulations  concerning  human  resources  data  and  their  relevancy  to 
cycle. 


1.2  ARMY  DEVELOPMENT  CYCLE 

A  brief  review  of  the  Army  system  development  cycle  follows 
to  provide  a  basic  framework  for  understanding  the  responsibilities  of 
the  major  agencies  involved.  A  more  detailed  discussion  is  presented 
in  Appendix  B. 

Army  Regulation  (AR)  1000-1**  establishes  the  basic  policy 
for  the  acquisition  of  major  systems  and  is  based  upon  the  guidance  of 


IT 


AR  1000-1,  Basic  Policies  for  System  Acquisition,  April  1,  1978. 


the  Office  of  Management  and  Budget  (0MB)  Circular  A-109  and  Depart¬ 
ment  of, Defense  Directive  (DoDD)  5006.1  and  Instruction  (DoDI) 
5000.2.  . 

Figure  1-1  (reproduced  from  AR  1000-1)  summarizes  the 
development  cycle  for  major  systems  and  indicates  the  four  major 
milestones.  At  each  of  these  milestones,  the  status  of  the  system  is 
reviewed  and  a  decision  made  to  advance  to  the  next  stage  of  the 
development  process,  repeat  all  or  portions  of  the  previous  phase,  or 
terminate  the  process. 

The  Army  has  divided  the  responsibilities  of  the  system 
development  cycle  into  four  major  areas:  the  proponent  (or  user's 
representative),  the  materiel  developer,  the  operational  tester,  and 
the  logistician.  Guidance,  coordination,  and  Department  of  Defense 
(DoD)  interface  is  provided  by  the  Department  of  the  Army  (DA)  staff. 

1.2.1  PROPONENT 

The  system  proponent,  or  user's  representative,  is  the  US 
Army  Training  and  Doctrine  Conmand  (TRADOC).  TRADOC  plays  a  major 
role  in  the  development  process  and  its  major  responsibilities 
include: 

•  Preparing,  in  coordination  with  the  materiel 

developer  and  logistician,  the  Mission  Element  Needs 
Statement  (MENS),  which  justifies  initiation  of  a  new 
major  system  acquisition 

•  Preparing,  in  coordination  with  the  materiel 

developer  and  logistician,  the  Required  Operational 
Capability  (ROC)  and  associated  documentation 

•  Conducting  concept  evaluation  force  development  tests 
and  experiments  and  participating  in  force 
development  test  and  evaluation  (FDTE)  conducted  by 
others 
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AR  1000-1  is  currently  being  revised  to  reflect  recent 
modifications  to  DODD  5000.1  and  DoDI  5000.2.  These  revisions  are 
expected  to  fully  incorporate  the  provisions  of  0MB  Cir.  A-109. 


•  Monitoring  developmental  tests  (DTs);  participating 
in  operational  testing  of  selected  materiel  systems; 
and  planning,  conducting,  and  evaluating  operational 
tests  of  other  materiel  systems 

•  Assessing  a  proposed  materiel  system  for  training 
implications  and  planning  for  establishing  the 
training  programs  to  support  its  ultimate  deployment 

•  Determining  the  requirement  for  simulators  and 
training  devices  early  in  the  development  cycle 

•  Assessing,  in  coordination  with  the  system  developer 
and  logistician,  the  logistical  support  requirements 
of  materiel  systems  under  development 

•  Assessing  the  personnel  subsystem  proposed  to  support 
the  materiel  being  fielded  for  Military  Occupational 
Specialities  { MOS )  implications  and  planning  for 
personnel  acquisition  and  training. 


1.2.2.  Materiel  Developer 


The  Materiel  Development  and  Readiness  Command  (DARCOM)  is 
the  Army's  materiel  developer.  For  each  major  system  a  Project 
Manager  (PM),  chartered  by  the  Secretary  of  the  Army  and  assigned  to  a 
commodity  command,  acts  as  DARCOM' s  principal  agent.  The  PM  is 
responsible  for  developing  a  total  program  acquisition  strategy.  His 
primary  concern  is  the  development  of  the  system,  on  time  and  within 
funding  constraints.  Other  major  responsibilities  include  the 
following: 


•  Logistic  support  planning 

t  Preparing  baseline  cost  estimates  in  accordance  with 
the  work  breakdown  structure 

•  Preparing  the  outline  acquisition  plan,  acquisition 
plan,  resident  training  plan,  and  new  equipment 
training  plan 
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•  Developing  independent  parametric  cost  estimates  for 
the  system 

•  Producibility  engineering  and  planning 

•  Identifying  long  lead  time  component  requirements 

•  Formulating  the  initial  qualitative  and  quantitative 
personnel  requirements  information  (QQPRI)  and  MOS 
decisions 
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•  Awarding  the  contract  for  low  rate  initial  production 
and  initial  production  facilities 

•  Developing  of  technical  manuals  (TMs) 

•  Coordinating  with  the  operational  tester  for  required 
tests,  independent  evaluation  reports,  and 
appropriate  updates. 


As  the  focal  point  for  scheduling  and  funding,  the  PM  is,  in  practice, 
the  single  most  powerful  voice  in  the  system  acquisiton  cycle. 

1.2.3  Operational  Tester 

The  Army's  Independent  agent  for  operational  test  and 
evaluation  is  the  US  Army  Operational  Test  and  Evaluation  Agency 
(OTEA),  an  agency  of  the  Office  of  the  Chief  of  Staff,  Army  (CSA), 
generally  working  directly  with  the  Vice  Chief  of  Staff,  Army  (VCSA). 

OTEA  is  responsible  for  planning,  managing,  and  independently 
evaluating  all  operational  tests  (OTs)  for  all  major  systems.  OTEA 
will  generally  assign  the  conduct  of  an  OT  to  a  TRADOC  test  agency 
with  participants  from  a  field  unit. 

1.2.4  Logistician 

The  logistician  for  the  Army  development  cycle  is  the  US  Army 
Logistics  Evaluation  Agency  (LEA),  an  agency  of  the  DA  Deputy  Chief  of 
Staff  for  Logistics  (DCSLOG).  LEA's  activities  are,  however,  confined 
almost  entirely  to  review.  Logistics  requirements  are  generally  set 
by  TRADOC  and  logistics  planning  is  primarily  the  responsibility  of 
the  PM. 
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HUMAN  RESOURCES  GUIDANCE  IN  THE  DEVELOPMENT  CYCLE 


AR  1000-1  also  sets  forth  policy  on  human  factors 
engineering,  in  addition  to  policy  on  safety  and  health,  as  follows: 

•  The  number  and  skill  levels  of  personnel  required  and 
human  engineering  factors  will  be  included  as 
constraints  in  system  design.  Other  logistic 
constraints,  such  as  capability  and  availability  of 
existing  test  equipment,  transportability,  and 
maintenance  facilities,  will  be  included  in 
applicable  program  plans. 

t  Materiel  systems  developed  or  acquired  by  the  Army 
must  be  supportable  by  the  personnel  skills 
available.  Timely  training  support  must  be  provided 
to  sustain  operational  development  of  materiel  and 
personnel  support  planning  will  consider  the  growing 
number  of  women  in  the  Army.  Integration  of  the 
human  element  and  system  will  start  with  initial 
concept  studies,  be  progressively  refined  as  the 
system  progresses,  and  be  documented  in  the  logistic 
support  analysis  (LSA).  LSA  documentation  will  form 
the  basis  for  personnel  authorization  criteria, 
personnel  selection  and  training,  development  of 
training  devices  and  simulators,  and  planning  related 
to  human  factors.  Human  factors  considerations  will 
be  validated  during  DT/OT  as  part  of  the  system 
support  package. 


The  above  extracts  from  Army  regulations  certainly  indicate 
that  it  is  Army  policy  to  integrate  human  resources  data  into  the 
system  development  cycle  in  all  of  its  phases  from  concept  development 
through  demonstration  and  validation  to  full  scale  engineering 
development  and  Includes  operator/maintenance  personnel  and  training 
requirements.  The  regulations  even  provide  for  the  identification  of 
human  factors  research  required  to  support  the  training  requirements 
and  the  operational  concept.  In  fact,  the  regulations  would  seem  to 
provide  an  adequate  basis  for  using  human  resources  data  in  trade-off 
analyses,  interrelating  system  effectiveness  with  design  parameters, 
qualitative  and  quantitative  personnel  requirements,  and 
learning/training  dimensions  to  support  early  decisions. 
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It  is  pertinent,  then,  to  inquire  if  the  integration,  or  lack 
thereof,  of  human  resources  data  in  the  Army  has  affected  the  somewhat 
less  than  successful  development  of  automated  battlefield  systems, 
such  as  TOS  for  which  an  operations  concept  was  enunciated  more  than 
25  years  ago,  but  which  has  yet  to  be  fielded.  The  case  studies  on 
TOS,  SOTAS,  and  XM1  do  provide  insight  into  the  dilemna  and  are 
addressed  in  Section  II. 

Another  clue  can  be  found  in  the  regulations  themselves  in 
that  they  tend  to  place  a  rather  narrow  interpretation  on  "human 
engineering"  data  as  it  applied  to  concept  development  and  system 
design.  For  example,  AR  602-1  states  that  task  seouences  developed 
originally  for  personnel -materiel  task  allocation  and  determination  of 
personnel  compatibilty  will  be  used  to  the  maximum  extent  feasible  in: 

.  •  The  determination  of  personnel -materiel  interface 
requirements  (displays,  controls,  test  points,  and 
maintenance  tasks) 

•  The  development  of  new  or  revised  MOS  or  duty 
descriptions 

•  The  development  of  training  programs,  training 
equipment,  and  standards  for  training 

•  The  development  of  a  product  improvement  program 

•  The  assessment  of  human  performance  reliability.  The 
personnel  data  base  will  be  brought  up  to  date 
whenever  affected  by  design  or  configuration  changes. 

HFE  will  be  applied  to  planning  and  making  changes  in 
missions,  doctrine,  organizations,  and  equipment  to 
avoid  personnel -materiel  incompatibility. 


The  interesting  fact  is  that,  while  these  are  all  valid  applications 
of  task  sequencing  for  human  factors  considerations,  the  fundamental 
application  of  human  resources  data  to  an  initial  determination  of  the 
task  sequence  is  not  even  mentioned.  This  suspicion  is  confirmed  by 
examining  Figure  A-l  of  that  regulation,  reproduced  herein  as  Figure 
1-2,  which  purports  to  show  personnel  considerations  in  system 
effectiveness.  Again,  the  emphasis  is  on  the  narrow  ouestion  of 
optimizing  a  personnel -materiel  interface  that  has  already  been 
defined--not  on  determining  where  the  interface  should  be  in  the  first 
place. 


SYSTEM  DESIGN  FOR  PERSONNEL  •  MATERIEL  INTERFACE 


SECTION  II 


HUMAN  RESOURCES  DATA  UTILIZATION:  CASE  STUDIES  OF  TOS.  SOTAS  AND  XM1 


The  purpose  of  this  section  is  to  define  and  discuss  the 
utilization  (or  lack  of  utilization)  of  human  resources  data  in  the 
development  of  TOS,  SOTAS,  and  XM1.  Documentation  provided  by  the 
aovernment  and  detailed  technical  discussions  with  Department  of  the 
Army  personnel /defense  contractors  associated  with  each  system 
provided  the  bulk  of  the  data  for  these  case  studies.  A  iist  of  the 
documentation  required  under  the  current  system  acquisition 
regulations  is  contained  in  Table  2-1.  This  list  was  extracted  from 
the  regulations  reviewed  in  Appendix  B  and  is  presented  in  the 
sequence  the  documents  are  normally  written.  Since  TOS,  SOTAS,  and 
XM1  were  both  initiated  prior  to  the  implementation  of  current 
regulations,  the  documents  produced  in  support  of  these  programs  do 
not  track  exactly  with  the  reauired  list.  However,  the  correspondence 
of  retirements  for  documentation  between  the  old  and  new  regulations 
is  similar  enough  to  provide  a  reasonably  close  match. 

SAI  was  provided  supplemental  documentation  on  these 
programs,  above  and  beyond  that  minimally  required  to  support  the 
decision  milestones.  These  additional  documents  were  very  relevant  to 
this  study  effort  and  provided  for  a  more  thorough  development  of  the 
study  objectives.  References  to  these  documents  are  made,  where 
appropriate,  throughout  the  remainder  of  this  section. 

Detailed  technical  discussions  were  conducted  with  several 
Army  and  civilian  agencies-  The  participants  in  these  discussions 
were  generally  very  cooperative  and  provided  additional  insight  to  the 
available  documentation.  Accordingly,  a  more  thorough  understanding 
of  the  perspective  of  each  of  the  programs,  in  light  of  the  study 
objectives,  was  achieved  than  could  have  been  gained  solely  through  a 
document  review. 

The  synthesis  of  the  data  collection  and  discussions  to  date 
are  presented  in  the  paragraphs  that  follow.  TOS  is  discussed  first, 
followed  by  SOTAS  and  XM1. 


TABLE  2-1.  REQUIRED  DOCUMENTATION  FOR  MAJOR  SYSTEM  ACQUISITION 
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Mission  Element  Need  Statement 
Special  Task  Force  Report 
Letter  of  Agreement 
Task  Listing 

Decision  Coordinating  Paper  I 
Outline  Acquisition  Plan 
DT  I  Independent  Evaluation  Plan 
DT  I  Design  Plan 
DT  I  Report 

DT  I  Independent  Evaluation 
OT  I  Independent  Evaluation  Plan 
OT  I  Oesign  Plan 
OT  I  Report 

OT  I  Independent  Evaluation 

Training  Support  Plan 

Logistic  Support  Plan 

Preliminary  QQPRI 

Tentative  Basis  of  Issue  Plan 

Cost  and  Operational  Effectiveness  Analysis 

Cost  and  Training  Effectiveness  Analysis 

MOS  Evaluation 

Individual  and  Collective  Training  Plan 
Training  Device  Requirements 
Required  Operational  Capability 
Acquisition  Plan 

Initial  Recruit  and  Training  Plan 
Decision  Coordinating  Paper  II 
DT  II  Independent  Evaluation  Plan 
DT  II  Design  Plan 
DT  II  Report 

DT  II  Independent  Evaluation 
OT  II  Independent  Evaluation  Plan 
OT  II  Design  Plan 
OT  II  Report 

OT  II  Independent  Evaluation 
Final  QQPRI 
Basis  of  Issue  Plan 
MOS  Decision 

Draft  Tables  of  Organization  and  Equipment 
Updated  Training  Plan 
Updated  Acquisition  Plan 
Decision  Coordinating  Paper  II 
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TACTICAL  OPERATIONS  SYSTEM 
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The  current  Army  need  for  a  tactical  division-level  C  l 
system  is  expressed  in  the  TOS  ROC1. 

"Modern  Army  concepts  call  for  highly  effective 
land  combat  capabilities  for  the  conduct  of 
tactical  operations  in  any  intensity  of  conflict 
and  geographical  environment.  To  achieve  these 
capabilites,  the  Army  is  preparing  to  introduce 
important  families  of  sensors,  a  broad  range  of 
second-  and  thi rd-generation  SI6INT  [signal 
intelligence]  equipment,  and  other  battlefield 
systems.... Demands  for  information  concerning  the 
capabilities  and  actions  of  the  highly  mobile  and 
lethal  opposing  forces,  coupled  with  the  new  and 
improved  communications  and  battlefield  systems, 
have  created  a  mass  of  raw  data  for  which  an 
automated  tactical  operations  system  (TOS)  is 
required.  TOS,  a  command  and  control  system 
functioning  as  the  focal  point  for  those  new 
systems,  is  needed  to  provide  the  capability  to 
exchange  data  with  other  tactical  data  systems; 
data  base  management;  analysis  support;  and  the 
display  capability  required  by  these  modern  Army 
system  concepts.  Specifically,  TOS  Is  needed  to 
improve  the  functions  of  command  and  control,  and 
thereby  enable  the  commander  and  staff  to  more 
effectively  integrate  and  employ  the  battlefield 
systems  which  fight,  support,  and  sustain  the 
battle.... Emerging  intelligence  and  combat  systems 
will  provide  the  information  needed  by  the 
commanders  and  their  staffs  in  such  large  volumes 
that  traditional  manual  command  and  control  systems 
and  organizations  will  be  inundated.  Utilizing  the 
manual  system,  the  commander  and  his  staff  will  not 
be  able  to  respond  to  the  available  data  fast 
enough  to  enable  sound  and  timely  decisions  to  be 
made  and  implemented  for  effective  use  of  his 
resources." 
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PM  TOS,  Tactical  Operations  System  Required  Operational 


With  this  need  established,  the  mission  of  TOS  is: 

"...to  provide  the  command er  and  his  staff,  in  a 
timely  manner,  the  operations  and  intelligence 
information  that  they  require  to:  see  the  battle¬ 
field;  make  decisions  to  exploit  enemy  force 
weaknesses,  and  determine  courses  of  action  for  the 
effective  employment  of  friendly  resources.  As  a 
command  and  control  system,  TOS  shall  have  a 
secondary  mission  to  function  as  the  focal  point 
for  the  ^change  of  data  with  other  tactical  data 
systems. 

TOS  consists  of  an  integrated  assembly  of  hardware,  software,  and 
personnel  supported  by  the  existing  and  emerging  tactical 
communications  and  information  distribution  system. 

2.1.1  TOS  System  Description 

TOS  is  a  computer-assisted  tactical  information  processing 
system  that  primarily  supports  the  functional  areas  of  intelligence 
(62)  and  operations  (G3).  It  is  an  integration  of  hardware  (computer 
and  related  peripheral  equipment),  software  (computer  programs), 
computer  operating  data  (files  and  tables),  personnel  (system 
operators,  maintainers,  and  users),  and  standard  communications  means. 
Interface  with  the  computer  is  accomplished  through  the  use  of  message 
input/output  devices. 

A  specific  system  description  of  TOS  as  it  is  expected  to  be 
fielded  is  difficult  to  formulate  at  this  time.  As  will  be  discussed 
in  the  paragraph  on  the  history  and  current  status  of  the  development 
of  TOS,  it  has  evolved  through  many  configurations.  These  configu¬ 
rations  may  be  summarized  as  follows: 

•  From  1958-1964,  the  system  was  known  as  FIELDATA  and 
was  directed  at  the  field  army  level.  It  was  a 
display-oriented  system  that  provided  storage  and 
retrieval  of  selected  information. 


•  From  1964-1970,  the  system  was  known  as  European  TOS 
(EUROTOS),  or  Seventh  Army  TOS  (SATOS),  and  was 
directed  at  the  field  army  and  corps  levels.  The 
functional  uses  of  the  system  were  expanded,  but 
basically  it  remained  a  storage  and  retrieval  device. 

•  From  1970-1973,  the  system  was  known  as  Developmental 
TOS  (DEVTOS).  The  EUROTOS  hardware  and  software  were 
utilized  to  evaluate  automation  at  the  division  level 
during  Project  Modern  Army  Selected  Systems  Test, 
Evaluation  and  Review  (MASSTER). 

•  The  TOS  Operable  Segment  (TOS^)  (1971-1977)  effort 
was  also  directed  at  the  division  level,  and  utilized 
militarized  hardware  instead  of  commercial  hardware, 
but  remained  basically  a  storage  and  retrieval  device 
while  implementing  selected  functional  areas. 

•  Division  TOS  (DTOS)  (1973-1979)  improved  functional 
areas,  developed  additional  military  hardware  and 
addressed  alternative  configurations  down  to  and 
including  the  battalion  level. 

•  The  current  effort  is  designated  Executive/Con¬ 
trol/Subordinate  System  (ECS*)  and  will  include  field 
experimentation  in  Europe. 

The  system  description  that  follows  is  that  specified  in  April  1979, 
which  addresses  the  implementation  of  TOS  from  battalion  to  division 
level . 

TOS  shall  be  a  secure,  automatic  data  processing  system  which 
serves  the  command  and  staff  elements  of  the  division  at  the  Tactical 
Operations  Center,  Tactical  Command  Post  (TAC  CP),  subordinate  Brigade 
(BDE)  Conmand  Posts  (CPs),  subordinate  Battalion  Command  Posts,  a 
subordinate  Armored  Cavalry  Squadron,  and  support  liaison  points.  The 
system  shall  provide  the  capability  to  aid  the  commanders  in 
controlling  and  coordinating  tactical  operations  by  providing  for 
receiving,  processing,  storing,  retrieving,  and  disseminating 
information  concerning  the  status  and  location  of  friendly  and  enemy 
units.  The  TOS  shall  be  secure,  be  modular,  and  provide  for 
commonality  and  interchangeability  of  hardware  components  among  its 
functional  areas  and  with  other  Army  tactical  systems.  In  non- 
tactical  deployment,  the  system  shall  have  the  capability  to  permit 


training  of  user  personnel  without  affecting  its  mission-ready 
capability.  The  TOS  functions  of  collecting,  processing,  storing, 
retrieving,  and  disseminating  friendly  and  enemy  unit  information 
shall  be  carried  out  in  the  following  functional  areas: 

•  Division  Computer  Center  (DCC).  The  DCC  shall 
constitute  the  main  data  processing  and  control  point 
and  the  central  data  base  for  the  Division  TOS.  The 
DCC  shall  consist  of  a  data  base  processor,  a  front- 
end  communications  processor,  and  the  large  secondary 
memory  to  contain  the  TOS  Division  data  base.  The 
DCC  shall  be  secure,  be  modular,  and  provide  the 
capability  for  data  entry,  computation,  message 
generation  and  transmission,  message  edit  and 
validation,  display  and  print-out  of  messages,  and 
the  ability  to  control,  monitor  and  configure/recon¬ 
figure  the  digital  data  and  voice  nets  of  the  system. 

The  DCC  shall  also  generate  and  maintain  the  system 
data  base  and  disseminate  information  to  users. 

•  Tactical  Computer  System  (TCS).  The  TCS  shall  be  a 
compact,  modular,  secure  data  processor  and  shall 
provide  the  capability  for  data  entry,  computation, 
message  generation  and  transmission,  message  edit  and 
validation,  message  reception,  display  and  printout 
of  messages  in  graphic  and  text  format,  and 
monitoring  control  voice  and  digital  data  nets.  The 
TCS,  together  with  its  computer  programs,  is  the 
primary  constituent  of  the  Intelligence  Element  of 
the  Division  Tactical  Operations  Center,  Division 
Tactical  Command  Post,  and  the  Brigade  Command  Posts. 

•  Display/Keyboard  and  Printer  ( D/K/P ) .  A  TCS 
Display/Keyboard  and  Printer,  when  integrated,  will 
become  an  Analysis  Console. 

t  Tactical  Computer  Terminal  (TCT).  The  TCT  shall  be 
the  primary  input/output  device  of  the  system.  The 
TCT  shall  consist  of  a  microprocessor,  memory, 
display,  keyboard,  two  magnetic  tape  drives, 
communications  modem,  and  printer  for  hardcopy 
output.  The  TCT  shall  provide  the  capability  for 
data  entry,  message  composition,  editing  and 
validation,  message  transmission  and  reception. 


display  and  printout  of  messages  in  graphic  and  text 
format,  and  net  monitoring  of  digital  and  voice 
communication.  The  TCT  shall  be  modular  to  permit 
performing  functions  suitable  to  its  application.  To 
provide  maximum  flexibility  to  the  commander,  the  TCT 
shall  be  capable  of  being  operated  in  ground  vehicles 
and  command  aircraft. 

Figure  2-1,  reproduced  from  the  aforementioned  system 
specification,  depicts  the  TOS  system  configuration  within  the 
division.  The  TOS  elements  identified  in  the  figure  are  described 
below: 

a  Intelligence  Element.  The  Intelligence  Element  shall 
have  a  TCS  configured  with  three  D/K/Ps.  One  of  the 
D/K/Ps  shall  be  used  for  interactive  operator  control 
of  the  TCS.  This  operator  console  and  the  other  two 
D/K/Ps  shall  be  used  for  operational  interaction  for 
the  Analysis  and  Production  Section.  The  software 
shall  provide  for  the  interaction  with  three  TCTs, 
one  each  for  the  Reconnaissance  and  Surveillance 
Section,  Mission  Management  and  Dissemination 
Section,  and  the  Enemy  Situation  File  Manager.  The 
three  D/K/Ps  shall  be  capable  of  performing 
independent  actions  simultaneously.  For  instance, 
one  shall  be  able  to  compose  text  messages  while 
another  is  receiving  a  graphic  input. 

•  Operations  Element.  The  Operations  Element  shall 
contain  four  TCTs.  One  shall  be  for  61/G4  (plans) 
and  one  shall  be  for  G3  (operations).  In  addition, 
one  shall  be  used  by  the  Fire  Support/G3  Air/Division 
Airspace  Management  Element  and  one  shall  be  used  by 
the  G3  Plans/Friendly  Situation  File  Manager. 

•  TAC  CP.  The  TAC  CP  shall  have  a  TCS  configured  with 
two  D/K/Ps.  One  shall  be  for  the  G2  (intelligence) 
and  the  other  shall  be  for  the  G3  (operations).  In 
addition,  one  of  the  D/K/Ps  shall  also  function  as 
the  computer  operator's  console.  A  TCT  shall  be 
provided  for  the  division  commander.  The  two  D/K/Ps 
shall  be  capable  of  performing  independent  actions 
simultaneously  such  as  one  composing  text  messages 
while  the  other  receives  a  graphic  input. 


•  BDE  CP.  The  BDE  CP  shall  have  a  TCS  configured  with 
two  D/K/Ps.  One  shall  be  for  S2  and  the  other  shall 
be  for  the  S3.  In  addition,  one  D/K/P  shall  be  used 
for  computer  operator  control  actions.  A  TCT  shall 
be  provided  for  the  BDE  commander  and  up  to  five 
remoted  TCTs  shall  be  interfaced  with  the  BDE  CP  for 
battalion  commanders.  The  capability  shall  be 
provided  to  interface  additional  TCTs  with  BDE  CP. 
The  two  D/K/Ps  shall  be  capable  of  performing 
separate  actions  simultaneously  such  as  one  composing 
text  messages  while  the  other  receives  a  graphic 
input. 

•  Maneuver  Battalion/Other  Division  Units.  DTOS 
supports  the  maneuver  battalions  and  other  divisional 
units  with  a  remote  input/output  TCT  on  the  basis  of 
one  per  designated  unit. 

2.1.2  TOS  History  and  Current  Status 


The  first  investigation  concerning  the  possible  development 
of  automated  systems  to  support  tactical  command  and  control 
operations  for  the  Army  was  a  study  program  and  a  series  of  tests 
undertaken  in  1956  by  the  Signal  Corps.  In  1958,  the  US  Army 
Intelligence  Board  conducted  a  study  defining  user  requirements  for 
automated  combat  intelligence.  Simultaneously,  five  functional 
subsystems  for  command  and  control  were  identified  for  automated  data 
processing  applications:  fire  support,  intelligence,  operations, 

logistics,  and  personnel  and  administration.  These  efforts  provided 
the  initial  frame  of  reference  for  subsequent  TOS  development.  TOS 
requirements  were  refined  at  Fort  Huachuca  through  1964. 

During  this  same  period,  the  Army  Tactical  Operations  Center 
(ARTOC)  project  provided  further  insight  into  storage,  retrieval,  and 
display  techniques  of  selected  information.  The  First  Intelligence 
Simulation  Test  (FIST),  conducted  at  Fort  Huachuca  in  June  1962, 
confirmed  the  feasibility  of  applying  automatic  storage  and  retrieval 
techniques  to  the  processing  of  tactical  intelligence.  An  ARTOC 
facility  was  established  at  Fort  Leavenworth  in  1963.  Exercise  Major 
Domo  in  1964  confirmed  the  feasibility  and  desirability  of  ADP  support 
for  the  command  and  control  function. 


t - 

Using  current  terminology,  this  phase  of  TOS  development  would 
correspond  to  the  conceptual  or  continuing  analysis  of  mission 
area  phase  of  the  system  acquisition  cycle. 


2-9 


Milestone  0,  or  the  program  initiation  milestone,  was  reached 
in  1964,  when  the  Department  of  the  Army  terminated  activities  at  Fort 
Huachuca  and  assigned  US  Army,  Europe  (USAREUR)  the  mission  to 
develop,  install,  operate,  and  evaluate  a  developmental  TOS  and  to 
identify  functional  areas  within  a  field  army  where  automation  could 
assist  commanders  in  the  conduct  of  operational  applications.  This 
concept  of  applying  automation  to  selected  aspects  of  a  military 
information  system  was  to  provide  “an  incremental  approach  to.  the 
introduction  of  automation  for  use  in  the  development  of  TOS"4  as 
reported  by  USAREUR  and  Seventh  Army.  The  incremental  approach  was  to 
be  achieved  by  expanding  functional  areas  and  user  associated 
capabilities  to  the  basic  software  package.  Thus,  design  and 
implementation,  design  verification  testing,  and  system  evaluation 
were  to  proceed  concurrently. 

Through  June  1968  only  limited  hardware  and  software 
capabilities  were  developed  and  tested  by  Seventh  Army.  The  primary 
functional  areas  examined  during  the  period  were:  Friendly  Unit 

Information,  Enemy  Situation,  Nuclear  Fire  Support,  and  Effects  of  the 
Enemy  Nuclear  Strikes.  These  limited  capabilities  provided  for 
computation,  dissemination  of  information,  compilation  of  summary 
reports,  and  preparation  of  responses  to  requests  for  information  from 
within  and  among  the  system  subscribers  at  division,  corps,  and  army 
levels.  Because  the  emphasis  of  the  developmental  effort  was  to  be  on 
software  concepts  and  techniques  rather  than  hardware  research  and 
development.  Seventh  Army  used  "off-the-shelf"  commercial  eouipment 
and  existing  tactical  communications  to  create  a  system  known  as 
EUR0T0S,  or  SATOS. 

EUR0T0S  was  evaluated  during  Seventh  Army  exercises 
culminating  in  Command  Post  Exercise  Cardinal  System.  The  results 
were  compared  Qualitatively  with  a  manual  baseline  evolved  from 
earlier  exercises.  Although  not  all  development  objectives  were 
achieved.  Seventh  Army  found  that  EUR0T0S  significantly  improved  the 
thoroughness  and  speed  of  information  dissemination  and  that  the 
compilation  of  information  and  data  in  the  form  of  summary  reports  was 
significantly  faster  at  army  and  corps  level  with  the  assistance  of 
EUR0T0S.  The  system  provided  some  improvement  in  the  performance  of 
computational  tasks.  Retrieval  of  information  was  significantly 
faster,  more  accurate,  and  generally  as  complete  as  in  the  manual 
system.  When  the  performance  was  poor  in  comparison  to  the  manual 
system,  the  fault  appeared  to  be  with  specific  software  design 
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problems  capable  of  correction.  The  overall  evaluation^  favored 
automated  data  processing  over  manual  processing  of  messages. 

In  January  1970  DA  directed  the  transfer  of  the  system  to  Fort  Hood  to 
continue  the  refinement  of  TOS  concepts  and  to  participate  in  Project 
MASSTER.  Based  upon  the  USAREUR  and  MASSTER  findings,  the  Army 
decided  to  direct  its  efforts  towards  the  development  of  a 
computer-assisted  command  and  control  system  for  the  division  and  its 
subordinate  units.  Additional  MASSTER  test  results  validated  the 
EUROTOS  findings,  but  noted  that  a  high  error  rate  in  message  text  was 
introduced  in  comparison  with  the  non-automated  system.  These  high 
error  rates  were  attributed  to  man-machine  interface  problems. 
MASSTER  experiments  were  constrained  by  commercial  equipment,  lack  of 
sufficient  input/output  devices,  and  the  limitations  of  functional 
software.  However,  the  Army  assumed  that  the  error  rates  could  be 
controlled  and  concluded  that  selective  automation  of  storage, 
retrieval,  and  dissemination  functions  would  provide  the  commander  and 
his  staff  with  an  improved  capability. 

A  study  group  was  formed  during  July  1971  under  the  newly 
chartered  Project  Manager,  Army  Tactical  Data  Systems  (ARTADS)  to 
develop  a  set  of  procurement  specifications  for  use  in  the  acquisition 
of  TOS  hardware  and  software.  Previous  studies  and  tests  results  were 
to  be  used  as  the  baseline  set  of  user  requirements. 

Guidance  for  the  conduct  of  the  study  was  provided  by  the 
Assistant  Vice  GJiief  of  Staff,  Army  (AVCSA)fiand  by  PM  ARTADS.  This 
guidance  for  TOS'1  is  sunmarized  as  follows:  0 

•  Use  already  developed  militarized  automated  data 
processing  equipment  as  the  computer  hardware  for  the 
TOS^  as  much  as  possible. 


•  Determine  whether  software  developed  for  other  Army 
systems  and  other  Service  systems  could  be  applied  to 
TOS  . 


5  Ibid- 

6  9 

PM  ARTADS,  Tactical  Operations  System  Operable  Segment  (TOSf), 
System  Engineering  Study  fteportT  Fort  Monmouth,  hlJ :  Tl 


•  Direct  TOS  efforts  toward  making  an  early 
significant  step  forward  in  conmand  and  control, 
based  initially  on  austere  requirements,  and  do  not 
be  delayed  by  attempts  to  perfect  technical 
solutions. 

o 

•  Field  the  militarized  TOS  as  soon  as  practicable  for 
testing  by  MASSTER,  but  preserve  the  option  for 
subsequent  proliferation  of  system  components  which 
prove  acceptable  for  a  division  system. 

2 

t  Limit  TOS  to  the  existing  division  communications 
system. 

•  Use  the  Draft  Basic  System  Description  for  Army-wide 
TOS,  as  modified  by  DA,  as  a  basic  requirements 
document.  Use  the  Functional  System  Design 
Requirements  for  Friendly  Situation/Enemy  Situation, 
and  Army  Air  Operations  as  the  baseline  requirements 
documents  for  these  specified  applications. 

•  Use  computer  performance  evaluation  models  to  help 
size  and  time  the  system  and  to  help  develop  the 
design. 

•  Employ  one  central  computer  center,  two  remote 
computer  centers,  sixteen  message  input/output 
devices,  and  eighteen  message  input  devices.  Examine 
this  basic  configuration,  and  recommend  changes  if 
required. 

The  study  results^  were  approved  by  AVCSA  in  February  1972  and  a 
contract  was  awarded  to  Litton  -Industries  June  1972. 
Concurrently,  DA  directed  that  the  TOS^  software  was  to  be  developed 
by  the  US  Army  Computer  Systems  Cownand  under  the  sponsorship  of  the 
PM  ARTADS. 

Demonstration  and  validation  testing  of  the  TOS  was  conducted 
during  March-April  1976  and  May-July  1977.  the  first  evaluation  was  a 


The  SES  Report  (ibid.)  is  comparable  to  the  Special  Task  Force 
Report  specified  in  current  regulations. 
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This  decision  was  equivalent  to  Milestone  1  or  the  approval  of 
for  the  system  to  enter  the  demonstration  and  validation  phase 
of  system  acquisition. 


LI 


K 


K 


a  v j ifj r*; i»j i.1  fj jj  j  j  f.  pj pi .«. 


r^rr^rr-r-' 


r»r^r»Tfl 


conmand  post  exercise  (FM120)  and  the  second  a  field  command  post 
exercise  (FM222),  both  conducted  at  Ft.  Hood,  Texas  by  the  TRADOC 
Combined  Arms  Test  Activity.  •  Although  detailed  and  well- 
instrumented  tests  were  planned,  TOS  was  not  available  for  FM120  (due 
to  software  errors  and  faults);  and  a  major  portion  of  its  projected 
capability  was  inoperative  (primarily  Standing  Request  for  Information 
feature). during  FM222. 

FM222  was  a  combined  OT  I/OT  I/FDTE  designed  to  develop 
requirements  and  recommendations  for  the  Milestone  II  decision.  The 
independent  evaluation  of  TOS  found  that  "overall,  the  TOS  did  not 
provide  a  significant  benefit  to  the  commanders  and  staff  elements 
during  FM222.  They  further  concluded,  however,  that  "TOS  reasonably 
can  be  expected  to  mature  into  a  system  which  will  provide  significant 
assistance  in  furnishing  more  timely  and  complete  enemy  and  friendly 
situation  data  to  commanders  and  primary  staff. ..and  that  the.  TOS 
program  should  proceed  into  full  scale  engineering  development." 

In  early  1977  a  TRADOC  System  Manager  (TSM)  was  appointed  for 
TOS  as  the  focal  point  for  TRADOC  efforts.  He  was  deeply  involved  in 
a  major  Combined  Arms  Center  (CAC)  effort  to  establish  division  and 
corps  level  software  requirements.  He  was  also  instrumental  in 
initiating  action  on  a  TOS  training  program. 


t rr 


A  special  Army  Systems  Acquisition  Review  Council  (ASARC)  in 
September  1977  rejected  ^arly  fielding  of  TOS  in  fiscal  year  1979  in 
favor  of  a  continued  TOS^  test  bed  to  address  problem  areas  to  include 
additional  human  factors  considerations.  A  refurbished/enhanced 
system  was  to  be  sent  to  Ft.  Hood  for  training  and  evaluation,  while 
two  systems  were  to  be  sent  to  Europe.  The  ASARC  II  (in  January  1978) 
approved  those  findings,  although  the  the  European  fielding  was 
reduced  to  one  system,  and  directed  that  the  program  be  continued  and 
proceed  to  the  full  scale  engineering  development  phase  of  the  system 
acquisition  process. 


Staff  members  of  Office  of  the  Secretary  of  Defense  (OSD) 
objected  to  this  decision  when  the  program's  status  was  reviewed. 
Subsequently,  the  Principal  Deputy  Under  Secretary  of  Defense 
(Research  and  Engineering)  in  October  1978  directed  the  Army  to 
complete  several  actions;  the  foremost  was  "to  demonstrate,  with  test 
results,  the  military  use  of  automation  to  assist  division  tactical 
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OTEA,  Independent  Evaluation  of  the  Tactical  Operation  System. 
Falls  Church,  VA:  January  1978. 

10  Ibid.,  p.  vii . 
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command  and  control  operations."11  The  Army  was  responsive  to  these 
concerns  in  their  revisions,  which  provided  for  development  and  test 
of  three  alternative  configurations  of  Division  TOS,  leading  to  a 
Defense  Systems  Acauisition  Review  Council  (DSARC)  II  consideration  in 
1982.  Subsequent  OSD  guidance  stated  that  the  military  utility  of  the 
system  was  to  be  demonstrated  at  alternative  levels  of  automation,  and 
that  the  Army  should  be  ready  for  a  production  decision  at  DSARC  II. 

Specific  information  concerning  the  alternative  levels  of 
automation  and  explicit  configurations  of  TOS  that  will  be  evaluated 
during  future  tests  were  not  available  to  the  study  team.  However, 
during  discussions  held  with  the  Office  of  the  Project  Manager  (0PM) 
TOS  it  was  learned  that  within  a  command  echelon  the  configuration 
will  basically  remain  the  same.  Future  tests  will  examine  to  what 
level  below  division  automation  should  be  applied  to  assist  the 
commander  and  his  staff  in  their  command  and  control  functions. 

2.1.3  Utilization  of  Human  Resource  Data  During 

TOS  Development 

2. 1.3.1  BESRL  Support  to  EUROTOS 

During  the  EUROTOS  period  the  predecessor  to  ARI ,  the  US  Army 
Behavioral  Science  Research  Laboratory  (BESRL),  provided  support  to 
the  TOS  program  with  both  field  and  laboratory  approaches.  The  field 
approach  was  implemented  through  the  BESRL  Field  Branch  in  residence 
at  the  Seventh  Army  TOS  in  Heidelberg,  Germany.  A  number  of 
conclusions  derived  from  these  studies  are  discussed  below. 

Research  was  conducted  to  compare  the  use  of  electro¬ 
mechanical  devices  to  electronic  devices  for  TOS  input  and  output. 
Teletypewriters  were  compared  to  cathode  ray  tubes  (CRTs)  with 
typewriter  keyboards.  B^RL  concluded  that  TOS'  use  of  CRTs  was,  in 
fact,  the  superior  mode. 

The  transform  operation  is  the  process  of  translating  free 
text  into  a  standard  system  format.  A  considerable  amount  of  effort 
was  expended  on  analyzing  the  TOS  transform  operation.  Experiments 


** US  General  Accounting  Office,  Tactical  Operations  System 

Development  Should  Not  Conti nue~as  Planned.  Washington,  D.C.: 
November  20,  1979. 

12  Seymour  Ringel,  James  D.  Baker,  Michael  Strub,  and  Loren  K. 
Kensinger,  Human  Factors  Research  in  Command  lnfg[*Blf^on 
Processing  Systems--Summary  of  Recent  Studies,  TDR  1158.  BESRL, 
Arlington,  YA:  July  1969,  p.  3.  ~ 
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were  conducted  to  examine  the  interface  between  the  action  officer 
(AO)  and  the  User  Input/Output  Data  (UIOD)  operator  and  to  reduce 
formatting  efforts  during  input. 


EUROTOS  called  for  both  an  AO  and  a  UIOD  operator.  The  AO 
selected  a  message  format  and  filled  it  out,  then  gave  it  to  the  UIOD, 
who  entered  onto  the  CRT.  BESRL’s  recommendation  was  to  merge  the  two 
position's  and  have  the  AO  also  enter  the  data  directly  into  the 
system. 


An  analysis  of  the  input  process  showed  an  error  rate  of  22% 
in  the  selection  of  message  format.  A  job-aid  was  developed  to  assist 
in  format  selection.  Tests  showed  that  no  improvement  in  the  error 
rate  resulted.  It  was  concluded  tliat  the  process  itself  needed  to  be 
changed,  rather  than  merely  aided. 

Research  was  conducted  comparing  graphic  vs  alpha-numeric 
methods  of  data  presentation.  This  was  motivated  by  the  fact  that, 
while  much  information  is  traditionally  displayed  in  graphic  forms 
(e.g.,  map  symbols),  TOS  stored  all  information  alpha-numerical ly.  It 
was  determined  that  there  was  no  degradation  due  to  use  of  all 
alpha-numeric  displays.  BESRL  reconmended  that  all  alpha-numeric 
displays  be  used.  (Since  then,  of  course,  the  state-of-the-art  of 
mini -computers  has  advanced  so  that  TOS  can  incorporate  graphics 
displays.) 

Procedures  then  employed  by  Seventh  Army  called  for  the  62  to 
apply  a  6-point  accuracy  rating  and  6-point  reliability  rating  to  each 
spot  report.  Experiments  with  job  aids  improved  neither  speed  nor 
accuracy.  BESRL  recommended  simplifying  the  rating  method,  perhaps  by 
the  use  of  subjective  probabilities.13 


13  - 

J.D.  Baker,  D.U.  Mace,  and  U.M.  McKendry,  The  Transform  Operation 
in  TOS:  An  Assessment  of  the  Human  Component,  TRN  2l2.  BESRL". 
Arlington,  VA:  July  1969. 
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F.  L.  Vic i no  and  S.  Ringel,  Decision  Making  with  Updated  Graphics 
vs.  Alpha-Numeric  Information,  TRN  178.  BESRL,  Arlington,  VA: 
November  1§66. 
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BESRL  also  noted: 


"One  of  the  very  real  problems.. .deals  with  the 
impact  of  automation  on  Seventh  Army  users.  In  the 
research-development-production-distribution  gamut,  those 
in  the  research  environment  may  lose  sight  of  the  fact 
that  users  of  the  new  system  may  not  be  as  intimately 
acquainted  with  them  as  are  the  research  scientists  who 
design  them.  User  reaction  to  a  new  product  must  be 
favorable--a  successful  research  program  maygbe  nullified 
by  a  user's  refusal  to  accept  innovations."1 


Research  was  also  conducted  on  the  potential  use  of  tactical 
decision  aids.  BESRL  concluded  that  computer  aids  to  tactical 
decision  making  may  yield  substantial  payoffs  in  combat  situations 
about  which  the  data  are  typically  conflicting  and  of  low  reliability. 

2. 1.3. 2  System  Engineering  Study 

The  next  major  milestone  of  TOS  was  the  System  Engineering 
Study  (SES)  Report  of  1971.  1  The  team  organized  under  this  ambitious 
effort  was  given  detailed  guidance  which  included  the  use  of  developed 
or  "off-the-shelf"  militarized  computer  hardware  and  the  continuation 
of  TOS  as  a  storage  and  retrieval  device.  The  emphasis  was  on  early 
fielding  of  the  system  based  "initially  on  austere  requirements  and 
not  be  delayed  by  attempts  to  perfect  technical  solutions."  It  is 
obvious  that  time  and  funds  were  of  the  essence  and  prevented  the  TOS 
team  from  examining  all  aspects  of  the  system  design. 

The  TOS  team  (without  the  benefit  of  any  assigned  applied 
psychologists)  produced  a  voluminous  report  specifying  the  adoption 
of  existing  hardware  and  the  development  of  software  for  the  TOS^  test 
bed.  The  selected  configuration  (hardware,  software,  and  user/ 
operator  personnel)  was  dictated  by  the  force  structure  which  the 


^  Ibid.,  pp.  7-8. 

^  SES  Report,  op.  cit. 
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system  is  designed  to  support  and  the  general  hardware  configuration 
as  developed  in  previous  test  reports  and  studies.  The  actual  number 
of  user  devices  for  TOS  were  provided  as  guidance  to  the  study  team, 
so  there  was  very  little  opportunity  to  examine  alternative 
configurations. 

Accordingly,  the  SES  report  was  directed  at  the  technical 
aspects  of  selecting  off-the-shel £  military  hardware  which  would 
satisfy  the  requirements  for  a  TOS^  test  bed  and  fully  define  the 
functional  areas  to  be  implemented  in  the  software  during  the  test  bed 
phase  of  the  development.  An  analysis  of  the  report  yields  no 
information  that  would  indicate  that  human  resources  or  human  factors 
were  given  any  consideration.  Even  the  TOS  acquisition  management 
plan,  which  was  one  of  the  products  of  the  study,  only  addressed  human 
factors  from  a  quality  assurance  perspective  in  that  “...provisions 
should  ensure  simplicity  and  understandabil ity  of  software  imple¬ 
mentation,  operations,  training  and  reference  material  with  respect  to 
man/system  interface;  and  the  application  of  human  factor  skills  and 
techniques  in  system  and  software  design  phases  such  as  coding  schemes 
and  message  lengths.  u  No  guidance  or  direction  was  forthcoming  from 
the  study  or  the  management  plan  which  indicated  that  human  resources 
would  or  should  be  given  proper  consideration  in  the  system. 

2. 1.3. 3  HEL  Support 

2 

Based  upon  the  SES  report,  the  development  of  TOS  test  bed 
was  undertaken.  From  a  review  of  the  available  documentation  and 
technical  discussions  with  personnel  associated  with  the  program,  it 
is  apparent  that  personnel  familiar  with  human  factors  applications  to 
system  design  were  not  involved  in  the  program  until  late  1975. 
During  FM120  and  FM222  the  US  Army  Human  Engineering  Laboratory  (HEL) 
evaluated  “the  TOS^  test  bed  software  and  systems  integration. ..hard¬ 
ware  was  not  evaluated  except  In  isolated  cases  because  it  was 
evaluated  on  the  TACFIRE  system. The  primary  objective  of  HEL's 
evaluation  was  to  “observe  system  use  and  prepare  recommendations  that 
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would  simplify  the  maiu-machine  i 
skill  requirements."  This 


nterfaces  and  reduce  user  training  and 
implies  that  the  objective  was  to 


evaluate  the  "how"  of  the  interface  and  not  answer  the  more  funda¬ 
mental  questions  of  "who,"  "where,"  and  "why"  of  the  system  design. 
The  HEL  tasking  was  too  narrow  in  scope  and  lacked  sufficient 
resources  to  answer  those  latter  questions. 


Nevertheless,  HEL  was  able  to  offer  many  recommendations, 
based  upon  FM120,  that  would  simplify  the  man-machine  interface 
considerably.  Many  human  factors  problem  areas  were  identified  and 
many  solutions  were  provided.  Most  of  the  HEL  report  centered  around 
the  Message  Input/Output  Device  (MIOD)  and  the  computer  center 
operator/system  controller.  HEL's  recommendations  concerned  the 
implementation  of  an  interactive  dialogue  with  a  cueing/prompting 
feature  to  the  operator  in  order  to  reduce  the  number  of  keying 
actions  required  of  the  operator  to  store  and  retrieve  information 
from  the  MIOD  or  to  initialize  and  maintain  the  system.  These 
"devices"  require  the  operator  to  be  a  relatively  proficient  typist 
and  to  learn  a  large  number  of  rules  and  codes  to  use  and  enter  data 
into  the  software  display  formats.  These  skills  are  not  normally 
associated  with  the  MOSs  of  those  personnel  who  would  be  expected  to 
fill  these  positions  within  the  manual  system.  It  was  apparent  from 
the  HEL  report  that  the  lack  of  human  factor  and  personnel 
considerations  in  the  design  stage  of  TOS  had  produced  a  system  that 
was  very  unsatisfactory  from  the  operator’s  point  of  view. 


HEL  also  participated  in  the  evaluation  of  TOS  during  FM222. 
It  is  significant  to  note  that  virtually  the  same  human  factors 
problems  uncovered  in  FM120  were  again  highlighted  during  this  test. 
This  was  to  be  expected,  since  only  a  year  had  elapsed  between  the  two 
tests.  This  time  period  would  be  insufficient  to  correct  all  the 
deficiencies.  The  independent  evaluation  report  on  FM222  concluded 
that  although  computers  can  be  used  in  the  field  by  troops: 


•  The  MIODs  are  unacceptable  as  input/output 
devices  for  TOS.  The  work  environment  in  the 
vicinity  of  the  MIODs  was  unsatisfactory  and  the 
devices  had  limited  capabilities. 

•  The  TOS  test  bed  formats  and  the  data  element 
dictionary  are  too  complex  and  rigid. 
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•  Information  availability  and  timeliness  were 
constrained  by  the  backlogs  and  workloads  at  the 
receiving  staff  sections.  TOS  probably  will  not 
significantly  improve  availability  or  timeliness, 
unless  it  assists  the  staff  in  rapidly  processing 
information  {for  example,  by  updating  files, 
notifyina  other  elements,  discarding  information, 
sorting,  categorizing,  and  changing  displays). 

•  There  is  a  substantial  opportunity  for  a  trade-off  of 
TOS  software  development  efforts  versus  human  factor 
acceptability  and  training  burden. 


All  of  the  above  conclusions  provide  ample  evidence  that 
human  factors  and  human  resources  were  not  adequately  considered 
during  the  design  and  development  of  TOS.  Consequently,  when  human 
operators  were  required  to  operate  the  equipment  in  a  test  environ¬ 
ment,  they  were  overwhelmed  by  the  man-computer  interface  problem. 
This  factor,  along  with  significant  hardware  and  software  design 
technical  problems,  ultimately  undermined  the  primary  objectives  of 
the  tests,  i.e.,  to  evaluate  the  operational  effectiveness  and 
military  utility  of  the  TOS  as  a  computer-assisted  command  and  control 
system. 


2. 1.3. 4  ARI  Research  on  Data  Entry 

During  the  DEVTOS  period  ARI  conducted  a  number  of  research 
projects  on  the  data  entry  process.  This  paragraph  provides  some 
brief  references. 

An  analysis  of  on-line  (using  the  terminal)  vs  off-line 
(using  paper  formats)  preparation  of  TOS  messages  with  and  without 
verification  was  conducted  in  a  laboratory  environment.  It  was  found 
that  on-line  verification  resulted  in  significantly  fewer  errors  with 
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no  reliable  difference  in  input  speed.  Verification  resulted  in 
reduced  errors,  but  at  a  time  and  manpower  penalty. 


The  use  of  feedback  in  TOS  training  systems  was  the  subject 
of  another  experiment.  It  was  found  that  feedback  could  reduce 
training  time  for  data  entry,  but  did  not  improve  accuracy.  The 
appropriateness  of  incorporatirui  feedback  into  TOS  training  depended 
upon  the  cost  of  training  time. 

Several  types  of  typing  aids  were  examined  to  assist  message 
entry  to  TOS.  While  no  increase  in  speed  could  be  found,  menu 
selection  was  found  to  reduce  the  number  of  errors. 

Two  types  of  reference  codes  were  used  in  early  versions  of 
TOS:  one  consisting  of  two  letters  and  number  ( LL# )  and  one  consist¬ 
ing  of  four  letters  (LLLL),  usually  an  acronym.  It  was  found  that  the 
latter  method  could  be  learned  in  60  percent  of-, the  time  of  the  former 
and  resulted  in  less  than  half  the  error  rate. 

The  Alpha-dot  system  is  a  non-standard  keyboard  where  the 
keys  to  be  pressed  are  determined  by  the  shape  of  the  alpha-numeric 
character  being  entered.  With  less  than  five  hours  practice, 
trainee's  using  the  Alpha-dot  tablet  were  abl&gto  enter  free  messages 
at  60  percent  of  their  standard  keyboard  rate. 


YA - 
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2. 1.3. 5  SIMTOS 


From  1967  to  1977  AR1  conducted  an  extensive  laboratory 
analysis  of  tactical  information  processing  under  the  rubric  Simulated 
Tactical  Operations  System  (SIMTOS).  In  spite  of  its  name,  SIMTOS  was 
not  a  simulation  of  TOS,  nor  was  it  ever  intended  to  be,  although  it 
did  employ  some  equipment  similar  to  SATOS.  SIMTOS  was  designed  for 
the  purpose  of  studying  human  performance  (i.e.,  decision  making)  in 
an  automated  tactical  military  information  setting.  An  extensive 
description  of  SIMTOS  and  its  research  program  is  not  possible  here, 
but  a  brief  discussion  is  appropriate. 

SIMTOS  was  a  physical  simulation  consisting  of  hardware  and 
software  where  players  (G2s  or  G3s)  were  presented  with  tasking  in  the 
context  of  a  scenario  and  data  base.  The  system  simulated  both  the 
player's  superiors  (who  contact  him  through  staff  memoranda  or  battle 
orders)  and  the  player's  staff  (with  whom  he  communicates  via  CRT  or 
teletypewriter).  Through  the  agency  of  the  computer  the  player  sees 
the  battle  action  unfold  before  him  and  he  takes  appropriate  steps  to 
execute  his  mission. 

The  earliest  formal  SIMTOS  research  was  a  series  of 
experiments  intended  to  evaluate  player  performance  measures  and 
identify  other  variables  which  correlated  with  them.  A  scoring 
standard  based  upon  the  expert  opinion  of  Army  Command  and  General 
Staff  College  (CGSC)  instructors  was  used  in  the  subsequent  analysis. 
Two  aspects  of  CGSC  (recency  of  attendance  and  class  standing)  showed 
strong  correlation  to  the  performance  criterion.  Analysis  concluded, 
however,  that  the  variables  analyzed  did  not  predict  player 
performance  consistently. 

Two  experiments  were  conducted  on  display  effectiveness.  One 
compared  tote  (alpha-numeric)  to  graphic  displays;  the  second 
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compared  standard  to  reduced-detail  maps, 
significant  differences. 


Neither  experiment  showed 
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A  series  of  two  experiments  were  conducted  to  explore 
the  use  of  decision  aids.  Two  situation  aids  and  one  resource 
allocation  aid  were  developed  and  tested.  In  neither  experiment  did 
the  player's  performance  differ  significantly  between  aided  and 
unaided  players. 

It  should  be  emphasized  that  while  the  SIMTOS  work  was  to 
some  extent  inspired  by  TOS,  SIMTOS  was  conducted  in  parallel  to  and 
not  part  of  TOS.  0PM  TOS  does  not  appear  to  have  utilized  the  SIMTOS 
results,  nor  to  have  appreciated  their  significance  to  the  TOS  effort. 

2. 1.3. 6  Summary  Discussion 

Most  TOS  subject  matter  experts  interviewed  by  the  SAI  study 
team  seem  to  believe  that  TOS  can  provide  an  enhanced  command  and 
control  capability  of  tactical  forces  at  the  division  level  if  only 
certain  aspects  are  corrected.  Many  of  these  corrections  involve  the 
proper  use  of  human  resource  considerations.  For  instance,  a  complete 
statement  of  functional  requirements  is  necessary  to  identify  and 
substantiate  the  needs  of  the  primary  user--the  battlefield  commander. 
These  requirements  have  never  been  developed.  Functional  requirements 
would  have  provided  the  basis  for  defining  what  the  system  is  required 
to  do  in  command  and  control  of  tactical  operations.  Instead,  it  has 
been  arbitrarily  assumed  from  the  beginning  that  TOS  would  be 
relegated  to  a  storage  and  retrieval  device  for  tactical  information. 
This  assumption  effectively  precluded  an  examination  or  consideration 
of  what  the  commander  really  does,  i.e.,  make  decisions. 

All  staff  procedures  may  be  categorized  into  one  of  the 
following  three  functions: 

•  Input  staff  processing 

•  Decision  making 

•  Output  information  processing. 
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Formal  Army  instruction  at  CGSC  in  command  and  staff  operations  and 
procedures  concentrates  on  the  decision  making  functions.  As  a 
result,  the  student  is  hardly  aware  of  the  decision  maker's  dependence 
on  the  two  information  processing  functions.  The  opportunity  for 
delays  and  errors  in  information  processing  is  far  greater  than  in 
decision  making,  and  their  impact  on  combat  outcome  is  more 
fundamental.  It  is  believed  that  the  developers  of  TOS  recognized 
this  fundamental  precept  and  designed  TOS  as  a  system  solely  designed 
to  collate  increasing  amounts  of  information,  faster,  and  with  minimum 
errors.  There  was  little  consideration  as  to  how  this  information  was 
to  be  linked  to  the  decision  maker.  Automated  functions  must  improve 
and  support  the  decision  making  of  the  commander  and  his  staff,  not 
merely  provide  him  automated  information. 

It  may  be  conjectured  that  thorough  functional  requirements 
analysis  to  determine  how  both  man  and  machine  should  be  utilized 
within  the  system  may  have  precluded  much  of  the  controversy  that 
surrounds  TOS  today.  For  example,  commanders  and  their  staffs  who 
have  used  -the  system  in  the  FM120  and  FM122  test  environment,  have 
said  that. 

•  "TOS  will  not  help  me  as  a  commander." 

•  "Cost  of  the  input  is  not  worth  the  information  out." 

•  "TOS  information  is  not  in  an  acceptable  form  to  me." 

•  "I  am  a  servant  to  the  software." 

•  "Computers  should  assist,  not  impose." 


All  of  these  comments  further  indicate  that  the  system  was  not 
designed  to  support  the  commander's  decision-making  functions  nor,  as 
some  have  said,  even  with  the  operator  or  ultimate  user  (namely,  the 
commander)  in  mind. 

It  has  been  argued  that  not  only  are  the  decisions  the 
prerogative  of  the  conmander,  but  also  the  manner  in  which  he  makes 
these  decisions.  If  this  assertion  is  accepted  as  valid,  then  it 
follows  that  TOS  should  be  no  more  than  a  storage  and  retrieval  device 
of  tactical  information  arrayed  within  well  defined  functional 
categories  in  a  manner  of  use  to  the  commander  and  his  staff.  In 


These  quotes  from  commanders  and  staff  involved  in  the  evaluation 
of  TOS  were  provided  to  the  SAI  study  team  by  US  Army  Materiel 
Systems  Analysis  Agency  (AMSAA)  personnel  who  observed  FM222. 


other  words,  there  is  no  requirement  to  provide  decision-aiding 
algorithms  like  those  previously  mentioned.  All  of  the  evidence 
indicates  that  this  is  the  assumption  under  which  TOS  ha^  been 
specified  within  the  SES  and  subsequently  developed  as  the  TOS*  test 
bed  for  evaluation  during  FM120  and  FM122. 

A  majority  of  the  problems  presented  in  the  OTEA's 
independent  evaluation  of  FM222"3  and  the  HEL’s  human  factor 
evaluation"”  might  have  been  avoided  if  studies  had  been  undertaken  to 
determine  crew  size  and  required  skills,  optimal  work  station  layouts, 
individual  and  crew  training  requirements,  operator-machine 
interactive  dialogue  techniques,  and  methods  for  commander  and  staff 
interaction  with  the  operator.  As  previously  mentioned,  comments  from 
the  two  reports  indicate  that  lack  of  attention  to  these  basic  human 
resource  considerations  led  to  major  problems  for  those  charged  with 
approving  the  continued  development  of  the  system.  These  problems  led 
Mr.  Hunter  Woodall,  Assistant  Deputy  Under  Secretary  of  the  Army 
(Operations  Research)  to  state  at  ASARC  II  "...the  human  factors 
problems  .were  not  insignificant. ..[they]  wouldn't  let  the  system  go 
forward."” 

Since  that  time,  HEL  has  been  working  very  closely  with  0PM 
TOS  and  the  TOS  software  support  center  to  correct  the  human  factors 
deficiencies  noted  in  FM120  and  FM222.  Personnel  from  HEL  indicated 
they  have  had  excellent  success  in  improving  prompting  aids,  reducing 
the  number  of  key  actions  required  of  the  operator,  and  lessening 
operator  dependence  on  the  data  element  dictionary.  As  a  result  of 
these  successes,  required  operator  typing  skills  have  been  reduced. 
HEL  has  also  been  able  to  provide  guidance  to  improve  the  software 
formats  and  reduce  the  errors  associated  with  inputting  of  data  into 
the  formats.  HEL  provided  trained  human  factor  personnel  to  observe 
how  the  man  functions  within  the  system,  his  strengths  and  his 
limitations.  Application  of  this  knowledge  to  the  design  of  the 
software  resulted  in  improved  man-machine  interface.  Ideally,  this 
human  factors  expertise  should  have  been  included  in  the  SES  effort  or 
at  least  provided  at  the  onset  of  the  TOS*  test-bed  development.  A 
concentrated  effort  is  currently  being  made  by  0PM  TOS  and  Singer 
Company,  who  is  developing  much  of  the  hardware  for  the  upcoming 
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Europe  evaluations,  to  correct  other  human  factor  problems  as  noted 
above.  The  study  team  was  not  able  to  ascertain  the  extent  or  the 
degree  of  success  of  this  effort. 

When  one  looks  at  the  whole  TOS  program  in  retrospect,  it  is 
very  easy  to  see  where  decisions  could  have  been  made  to  consider 
man's  role  in  the  system.  There  are,  however,  several  factors  that 
constrained  the  0PM  from  having  greater  sensitivity  to  human  factors. 

First,  after  the  issuance  of  the  SES  report,  TOS  effectively 
extended  the  demonstration  and  validation  phase  of  the  system 
acquisition  cycle.  Because  of  funding  and  schedule  constraints, 
TACFIRE  equipment  was  selected  as  the  baseline  hardware.  TACFIRE 
formats  and  information  processing  methods  were  chosen  as  guides  for 
future  TOS  software  development.  The  TOS  team  assumed  that  TACFIRE 
hardware  and  software  satisfied  all  human  factors  criteria. 

Second,  the  system  configuration  was  dictated  by  DA,  thus 
there  was  little  chance  to  experiment  with  different  manning  levels, 
etc. 

Third,  there  were  no  human  factors  personnel  or  applied 
psychologists  familiar  with  automated  data  processing  systems  on  the 
TOS  design  team.  Personnel  with  these  qualifications  are  trained  to 
recognize  potential  problems  and  can  often  recommend  solutions  or 
trade-offs  before  the  problems  occur  or  before  the  cost  of  changing 
the  system  or  subsystem  becomes  prohibitive.  During  TOS  development 
this  type  of  personnel  was  not  utilized  until  it  came  time  to  evaluate 
the  system.  They  were  not  utilized  during  the  design  of  the  system 
nor  to  assist  in  selecting  off-the-shelf  hardware. 

Fourth,  training  for  the  tests  was  inadequate.  System 
evaluations  prior  to  FM120  and  FM222,  for  example  EUR0T0S,  did 
demonstrate  that  field  troops  could  be  trained  to  use  the  system 
effectively.  However,  during  FM222,  the  unit  assigned  to  TOS  was 
trained  to  operate  the  system  during  off-duty  hours.  This  obviously 
is  not  conducive  to  establishing  a  good  training  environment,  but  PM 
TOS  had  no  control  over  the  situation. 

The  last  major  factor  which  prevented  inclusion  of  human 
resource  considerations  into  the  system  was  a  perceived  need  for  the 
immediate  development  of  an  automated  command  and  control  system. 
Almost  since  the  beginning  of  the  development  of  TOS  there  has  been  a 
sense  of  urgency  to  field  the  system  as  rapidly  as  possible- 
automation  for  automation's  sake  if  nothing  else.  In  hindsight,  with 
no  definitive  functional  requirements  and  with  the  normal  personnel 
turnover  experienced  throughout  all  the  agencies  involved  in  the 
development  of  TOS,  this  may  have  been  an  impossible  task. 


2.2 


STAND-OFF  TARGET  ACQUISITION  SYSTEM 


The  current  Army  need  for  a  target  acquisition  and 
surveillance  system  is  contained  in  the  SOT AS  ROC.  Although  the 
specific  need  is  classified,  it  may  be  summarized  from  the  open 
literature  as  follows: 

"During  the  conduct  of  tactical  operations  against  a 
major  well  organized,  highly  mobile,  modern  force, 
the  division  Commander  requires  timely  and  accurate 
information  about  the  battlefield  itself  and  those 
enemy  activities  which  may  affect  the  accomplishment 
of  his  mission.  The  Commander  requires  this 
information  to  more  effectively  concentrate  his 
combat  power  at  critical  times  and  places  and  employ 
his  supporting  arms.  Demands  for  this  information 
requires  a  system  for  detecting  and  locating  enemy 
targets  beyond  the  line  of  sight  from  ground 
positions.  The  system  should  operate  behind  the  FEBA 
[Forward  Edge  of  the  Battle  Area]  in  a  relatively 
secure  position  and  look  out  beyond  the  FEBA  to 
detect  the  movement  of  reserve  elements  of  the 
opposing  force,  together  with  the  build-up  of  second 
echelon  units,  in  order  that  they  can  be  engaged  by 
artillery  and  air  support.  It  is  necessary  that  this 
detection  and  location  capability  provide 
surveillance  over  a  wide  area,  and  tha±.  it  operate 
day  and  night  in  virtually  any  weather.'"30 


With  this  need  established,  the  mission  of  SOTAS  can  be  stated  as: 

"to  provide  the  Commander  and  his  staff  the 
capability  to  monitor  enemy  activity  on  the 
battlefield,  a  target  acquisition  capability  for 
engagement  of  targets  at  long  ranges,  and  a  system  to 
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collect  and  disseminate  _ttiis  tactical  information  on 
a  near-real  time  basis.  y 

From  the  above,  it  is  obvious  then  that  SOTAS,  like  TOS,  is 
also  an  emerging  C^I  system  that  is  being  developed  to  satisfy  the 
demand  for  improved  command,  control,  and  intelligence  collecting 
activities  ot  the  division  commander.  At  this  point,  it  is 
significant  to  note  two  primary  differences  between  the  systems.  TOS 
is  an  automated  C^I  system  being  developed  to  partially  replace  an 
existing  manual  system  which  is  central  to  the  conduct  of  tactical 
operations  for  the  division  commander.  SOTAS  is  an  automated  CJI 
system  being  developed  to  fill  a  void  in  the  existing  intelligence 
collecting  capability  oT  the  division  which  will  be  employed  in 
support  of  the  division  commander  during  the  conduct  of  tactical 
operations.  This  distinction  between  the  two  systems  and  its 
relevance  to  the  current  effort  will  be  discussed  below. 

2.2.1  SOTAS  System  Description 

3 

SOTAS  is  a  Cl  system  designed  to  collect,  display,  and 
disseminate  target  and  intelligence  data  to  tactical  unit  commanders 
in  a  combat  environment.  Accordingly,  it  will  provide  commanders  the 
capability  to  monitor  the  enemy  forces  on  the  battlefield  in  real  time 
and  acquire  moving  targets  beyond  the  FEBA  in  order  to  more 
effectively  deploy  forces,  direct  fire  power,  and  vector  aircraft  to 
targets. 

SOTAS'  development  has  been  evolutionary  in  nature.  Hence, 
the  system  description  is  itself  something  of  a  moving  target.  The 
description  presented  here  is  that  of  the  so-called  Interim-Interim 
(I*)  SOTAS  currently  deployed  to  Europe.  SOTAS  consists  of  three 
major  subsystems:  a  radar  mounted  on  an  airborne  platform,  a 
positioning  subsystem,  and  a  ground  display  subsystem.  A  brief 
description  of  each  subsystem  follows: 

t  The  airborne  subsystem  consists  of  a  UH-1H  helicopter 
equipped  with  a  moving  target  indicator  (MTI)  radar. 

(It  is  intended  that  the  production  SOTAS  will  use  a 
BLACKHAWK  helicopter.)  The  airborne  platform  is 
positioned  via  voice  vectors  so  that  the  radar  can 
detect  movement  on  or  near  the  ground  in  designated 
areas  or  sectors.  Radar  returns  and  platform 


positional  data  are  transmitted  to  the  ground  display 
station  via  air-to-ground  data  links. 


•  The  positioning  subsystem  is  a  portable  device  used 
to  provide  signals  to  the  airborne  platform  in  order 
for  it  to  pinpoint  its  location  relative  to  a  known 
reference  point.  It  also  provides  a  reference  point 
to  permit  the  calibration  of  the  antenna  pointing 
angle  as  calculated  by  the  heading  reference 
subsystem. 

•  The  ground  display  station  consists  of  a  twenty-foot 
processing  and  display  van  pulled  by  a  five- ton  truck 
with  a  sixty  KW  generator.  The  station  processes, 
displays,  and  disseminates  data  received  from  the 
airborne  platform.  Data  displays  use  synthetic  data 
to  develop  information  concerning  military  movement 
and  potential  targets.  This  information  is 
communicated  to  the  Division  users,  e.g.,  Division 
Artillery  (DIV  ARTY)  and  BDE  CPs.  The  van  houses  the 
SOTAS  operators  and  is  the  nerve  center  of  the  SOTAS 
system. 

The  current  SOTAS  employment  concept  provides  for  a  single 
ground  station  deployed  at  the  division  main  command  post.  Future 
plans  call  for  evaluating  secondary  ground  stations  at  each  brigade 
headquarters  in  addition  to  the  primary  ground  station. 

The  SOTAS  ground  display  station  requires  a  crew  of  four  to 
operate:  a  Target  Surveillance  Supervisor  (TSS)  (who  also  serves  as 
the  officer-in-charge) ,  two  Search  and  Track  Operators  (STOs),  and  a 
Radio-Telephone  Operator  (RTO).  The  following  description  was  derived 
from  the  systems  operating  procedures. 

The  TSS's  work  station  consists  of  a  standard  data  terminal 
with  alpha-numeric  keyboard,  status  display  and  a  map  digitizer. 

•  The  data  terminal  provides  hardcopy  records  while  the 
keyboard  is  used  by  the  TSS  to  interact  with  the 
system. 


TO - 

D.  M.  Larson,  B.  C.  Linge,  L.  M.  Heeringa,  K.  B.  Collyard,  F.  C. 
Foss,  SOTAS  Ground  Station  Operating  Procedures  (U).  Honeywell. 


•  The  status  display  provides  information  concerning 
the  status  of  targets  held  in  the  target  file,  system 
operating  parameters,  and  system  malfunctions. 

•  The  map  digitizer  is  a  back-lighted  map  table  with  a 
map  bug  which  allows  correlations  to  be  established 
between  military  maps  and  radar  data. 

•  The  TSS  monitors  all  tactical  communication  nets. 


Each  STO  performs  his  functions  at  a  display  console.  These 
display  consoles  are  the  primary  interface  between  the  SOTAS  crews  and 
the  radar  and  computer  subsystems.  The  displays  show  graphics, 
processed  MTI  radar  imagery,  the  target  file  data,  the  target  file 
index,  advisory  messages  to  the  operator,  real-time  cursor 
coordinates,  time  compression  paramet*»>-s ,  and  alpha-numeric  entries 
from  the  keyboard.  The  keyboard  allows  for  the  entry  of  Universal 
Transverse  Mercator  (UTM)  coordinates,  free  text  messages,  and  can  be 
used  for  graphics.  Each  STO  also  has  a  functional  keyboard  used  to 
control  the  imagery  on  the  display  or  to  direct  the  system  to  perform 
specific  actions. 

The  RTO  monitors  all  radios  and  communication  nets  required 
with  the  system. 

Figure  2-2,  provided  by  Honeywell,  depicts  the  layout  for  the 
SOTAS  primary  ground  station.  Figure  2-3,  also  provided  by  Honeywell, 
is  a  graphic  representation  of  the  information  flow  within  the  SOTAS 
system.  In  addition  to  providing  additional  insight  to  the  SOTAS 
system  description,  these  figures  are  key  to  the  incorporation  of 
human  resources  data  into  the  system  development.  As  such  they  will 
be  addressed  again. 

2.2.2  SOTAS  History  and  Current  Status 

0PM  SOTAS  placed  restrictions  on  the  documents  available  to 
the  study  teams.  Only  documents  directly  related  to  human  factors 
were  reviewed  and,  with  one  exception  (OTEA),  technical  discussions 
were  held  only  with  persons  in  0PM  SOTAS  or  with  support  contractors 
to  PM  SOTAS.  Even  the  available  test  results  were  developed  and 
analyzed  by  PM  SOTAS  or  its  support  contractors.  All  of  the 
evidence  presented 
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Even  DT/OT  I  was  conducted  by  PM  SOTAS,  somewhat  unusual  for  a 
major  system. 
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FIGURE  2-3.  SOT AS  INFORMATION  TRANSFER  MODEL 
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to  the  study  team  showed  the  "success-oriented"  attitude  expected  of  a 
project  management  office.  However,  even  with  this  caveat  in  mind, 
the  study  team  is  convinced  that  SOTAS  is  a  remarkably  successful 
program  and  an  excellent  example  of  how  human  factors/human  resources 
should  be  developed  and  integrated  in  a  military  system. 

The  SOTAS  evolved  from  the  Alerting  Long  Range  Airborne  Radar 
for  Moving  Targets  (ALARM)  feasibility  and  concept  tests  and  studies 
conducted  from  1970-1975.  During  this  concept  formulation  period  it 
was  demonstrated  that: 

•  A  standard  Army  helicopter  could  fly  with  a  rotating 
antenna. 

•  Radar  data  could  be  transmitted  to  a  ground  station. 

•  Time  compression  and  graphics  were  feasible  in  the 
display  element. 

Based  upon  these  feasibility  efforts,  the  Director,  Defense 
Research  and  Engineering  (DDRAEj^  directed  DA  in  1974  to  pursue  the 
development  of  SOTAS.  Effectively,  the  system  moved  into  the 
demonstration  and  validation  phase  of  the  system  acquisition  cycle. 
The  concept  for  the  continued  development  of  SOTAS  was  to  provide  for 
command  and  control  for  airborne  battlefield  surveillance  and  target 
acquisition  of  moving  targets. 

In  late  1974  PM  SOTAS  was  chartered  to  manage  the  development 
of  the  system.  PM  SOTAS  immediately  assembled  a  team  of  contractors 
to  support  program  development.  General  Dynamics  was  chosen  as  the 
prime  hardware  contractor.  Honeywell  Corporation  provided  human 
factors  expertise,  Systems  Planning  Corporation  (SPC)  provided  system 
analysis  capabilities,  and  Technology  Research  Corporation  provided 
advanced  radar  research;  these  three  support  contractors  were  not 
subcontractors  to  the  prime,  but  were  directly  responsible  to  the  PM. 
This  single  manager  technique  successfully  integrated  all  facets  of 
the  system's  development  by  providing  each  facet  an  equal  "voice" 
concerning  trade-offs  in  the  system  design.  With  the  exception  of  the 
hardware  contractor  this  team  is  still  with  the  program. 


Now  the  Under  Secretary  of  Defense  (Research  and  Engineering) 
(USD(RE) ) . 
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During  April-June  1975  the  Combat  Developments  Experimenta¬ 
tion  Comnand  (CDEC)  and  the  Electronics  Comnand  (ECOM)  conducted  SOTAS 
demonstrations  at  Hunter-Liggett  Military  Reservation  in  California. 
These  demonstrations  indicated  that  the  SOTAS  crew  were  able  to  detect 
and  track  moving  targets  and  vector  attack  helicopters,  that  trilater¬ 
al  on  does  not  improve  accuracy,  and  that  the  closed-loop  targeting 
capability  was  feasible. 

This  was  followed  later  in  1975  by  personnel  experiments 
conducted  by  Honeywell  Corporation  at  the  General  Dynamics  San  Diego 
facilities  to  provide  data  on  the  personnel  skills  required  to  operate 
the  sytem. 

Still  later  in  1975  the  Army  and  the  Air  Force  conducted 
tests  at  White  Sands  Missile  Range.  These  tests  comfirmed  the 
feasibility  of  SOTAS  to  provide  useful  target  acquisition  dpta. 

In  May  1976  SOTAS  had  its  first  field  trial.  The  SOTAS  team 
went  to  Korea  for  a  demonstration  of  its  ability  to  operate  with  the 
2nd  Infantry  Division's  All-Source  Intelligence  Center  (ASIC).  SOTAS 
again  demonstrated  its  potential.  The  OPM's  team  gained  valuable 
insight  into  operational  problems.  However,  one  of  the  most  important 
results  of  the  Korea  test  was  that  the  SOTAS  concept  was  favorably 
received  by  the  user  (after  initial  skepticism).  The  frequent, 

positive  interaction  between  PM  SOTAS  and  the  user  initiated  during 
this  test  and  carried  on  in  subsequent  field  trials  was,  in  the  study 
team's  opinion,  critical  to  the  development  and  acceptance  of  the 
SOTAS  system. 

During  1976,  1977,  1978,  -1979  SOTAS  participated  in  the 
annual  REFORGER  exercises  in  Europe.  During  each  of  these  exercises 
the  PM  SOTAS  was  able  to  validate  on-going  modifications  and  to  expand 
his  testing  objectives  from  narrow  feasibility  demonstrations  of  the 
concept  to  successful  integration  with  the  participating  divisions' 
tactical  operations  centers.  After  each  exercise,  modifications  were 
made  to  the  system  design  to  improve  its  potential  use  during  the  next 
exercise. 
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As  related  by  DPM  SOTAS  during  technical  discussions. 

The  REFORGER  76  test  satisfied  the  requirements  for  DT/OT  I. 


This  concept  of  modify  the  system,  test  and  validate  the 
modifications,  apply  additional  modifications,  and  then  retest  proved 
so  successful  in  converging  on  the  final  design  that  the  ASARC/DSARC 
II  decision  milestone  was  moved  up  to  March-August  1978.  At  that  time 
the  decision  was  made  to  enter  the  full-scale  engineering  development 
phase  of  the  system  acquisition  cycle.  A  competitive  Request  for 
Proposals  (RFP)  was  let  for  the  system  hardware.  The  prime  contract 
was  awarded  to  Motorola  in  1979.  PM  SOTAS  retained  the  support 
contractors  on  the  program,  although  their  tasking  was  modified  to 
reflect  current  system  design  and  development  objectives. 

O 

Also  in  1979  an  I  SOTAS  was  experimentally  fielded  in  Europe 
with  the  objective  of  refining  training  objectives  and  clarifying 
integration  of  the  system  into  the  intelligence  gathering  units  of  an 
Army  division. 

Currently  the  system  is  scheduled  to  undergo  DT  II/OT  II 
early  in  1982  with  ASARC/DSARC  III,  the  production  decision,  following 
in  the  fall  of  1982. 


2.2.3  Utilization  of  Human  Resources  Data 

During  SOTAS  Devel opment 

The  effective  employment  of  human  resources  data  in  the 
system  design  has  been  continuous  in  the  SOTAS  program  almost  since 
the  initial  milestone  review.  PM  SOTAS  recognized  that  several 
complex  human  engineering  problems  had  to  be  solved  before  SOTAS  could 
become  an  operationally  effective  system.  He  also  recognized  that 
human  factors  considerations  were  being  placed  in  a  secondary  role  to 
hardware  technology  when  system  design  trade-offs  were  being 
conducted.  Based  upon  his  recommendations,  0PM  SOTAS  contracted  for 
human  factor  support  from  Honeywell  Corporation  and  shifted  the 
responsibility  for  human  factors  considerations  from  General  Dynamics 
to  the  PM 1  s  office.  As  previously  mentioned,  0PM  SOTAS  also  assumed 
direct  responsibil ity  for  systems  analysis  and  radar  research  via 
support  contractors.  This  single  manager  concept  provided  independent 
channels  for  system  design  recommendations  to  the  office  with  charter 
responsibility  for  the  system.  This  management  concept  has  a  negative 
aspect  in  that  it  increases  the  span  of  control  for  the  0PM,  but  that 
does  not  appear  to  have  been  detrimental  in  the  case  of  SOTAS. 

Now  that  it  has  been  established  that  human  resources  have 
been  considered  in  SOTAS  development  the  question  remains:  "What  was 
done  and  when  was  it  done?"  Honeywell's  tasking  encompassed  the 
following  objectives: 


•  Determine  operator  functions  and  information 
requirements  related  to  the  total  SOTAS  coimtand  and 
control  environment. 

•  Provide  data  and  facilities  which  address  specific 
system  design  questions  and  issues  regarding  the 
operator's  role  in  system  operation. 

•  Recommend  procedures,  manning  levels,  aiding 
techniques,  training  requirements,  evaluation 
criteria,  and  HFE  Guidelines  throughout  the  course  of 
SOTAS  engineering  development. 

With  these  broad  objectives,  Honeywell  established  an  initial  program 
to  resolve  major  issues  and  then  continually  narrowed  their  focus  to 
refine  and  validate  resolutions. 

Figure  2-4  is  a  block  diagram  which  is  representative  of  this 
process.  As  can  be  seen,  it  provides  for  continual  refinement  of  any 
implemented  solution  and  the  identification  of  new  problem  areas. 
Honeywell  has  used  this  mechanism  to  provide  critical  input  to: 

•  Allocation  of  functions  between  individuals  and 
machines  to  include  aiding  techniques 

•  Number  of  operating  crew  and  their  structure 

e  Allocation  of  functions  among  crew  members 

•  Training  systems  analysis  for  both  individuals  and 
crew 

t  Information  flow  within  and  external  to  the  system 

•  Work  station  design  to  include  alpha-numeric/ 
functional  keyboard  layout,  information  formats  and 
work  space  arrangement 

•  Van  layout  to  include  operator  and  equipment 
positions. 

Honeywell  personnel  were  able  to  achieve  this  impact  on  SOTAS  due  to 
the  constant  exposure  afforded  the  system  to  user  personnel  and  the 
development  of  a  SOTAS  simulator. 
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As  previously  stated  SOTAS  was  observed  by  Honeywell 
personnel  during  the  Hunter-Liggett,  San  Diego,  and  White  Sands  tests 
and  all  REFORGER  exercises  from  1976  through  1979.  More  importantly 
than  just  observing  these  tests  and  exercises,  they  provided  human 
factors  objectives  to  be  achieved  during  each  exposure. 

Using  the  process  outlined  in  Figure  2-4,  they  provided 
system  design  recommendations  that  were  duly  considered  by  0PM  SOTAS 
before  proceeding  to  the  next  test  or  exercise.  Those  modifications 
that  could  be  reasonably  incorporated  considering  cost,  schedule 
and/or  hardware  trade-offs  were  implemented.  Other  modifications 
deemed  advisable,  but  with  major  cost  or  schedule  impacts  were  delayed 
until  full  scale  engineering  development. 

The  SOTAS  simulator  was  developed  at  Honeywell's  Minneapolis 
facility  and  used  continually  for  human  factors  studies  and  troop 
training.  SOTAS  is  the  only  major  system  known  to  the  study  team  in 
which  the  training  device  can  truly  be  said  to  have  evolved  with  the 
materiel  and  where  there  was  a  strong  interaction  between  training 
developments,  human  factor  design  consideration,  and  hardware 
development. 

Honeywell's  approach  to  resolving  human  factor  issues  were 
threefold:  3 

•  Continued  analysis  of  and  coordination  with  the 
ongoing  engineering  design  activities 

•  Application  of  principles  and  conclusions  derived 
from  field  and  experimental  data  to  guide  the 
formulation  of  system  concepts  and  design  trade-offs 

•  Use  of  the  SOTAS  simulation  facility  to  generate 
additional  data  to  guide  design  trade-offs  when  gaps 
existed  in  the  data  base. 

From  the  many  examples  of  Honeywell  human  factor  analysis  available, 
three  illustrative  examples  will  serve  to  indicate  the  depth  and 
breadth  of  methodologies  applied  to  the  SOTAS  design. 
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The  first  example  concerns  personnel  skills  required  to 
operate  the  system.  Human  factors  test  plans  were  developed  for  the 
San  Diego  test  in  1975.  The  test  demonstrated  that  the  most  important 
factor  in  selecting  SOTAS  crew  personnel  was  the  person's  experience 
in  the  Army,  not  his  MOS  training.  Honeywell  concluded  that  E-6's  and 
E-7's  were  required  for  the  STO  positions.  This  conclusion 
highlighted  a  career  development  problem,  since  the  Military  Personnel 
Center  (MILPERCEN)  requires  a  career  progression  for  operators.  What 
makes  the  SOTAS  experience  remarkable  is  that  this  problem  was 
surfaced  early  in  the  demonstration  and  validation  phase,  rather  than 
near  the  end  of  program  development. 

The  second  example  concerns  the  van  layout. ^  Field 
observations  had  indicated  that  certain  layout  variables  can  cause  an 
impact  on  overall  system  performance.  The  more  important  of  these 
variables  selected  for  increasing  overall  performance  were: 

•  Segregation  of  function  by  station 

•  Integration  of  work  station 

•  Interactive  distance 

•  Information-decision  action  proximity. 

47  4ft 

A  full-scale  mock-up  reproduction  and  link  and  visual  analyses 
were  used  to  evaluate  two  alternative  layouts.  The  evaluation  and 
analyses  of  proposed  designs  resulted  in  an  extensive  system 
reconfiguration.  It  is  interesting  to  note  that  both  designs  had 
implications  on  the  role  of  the  TSS.  In  the  selected  design  the  TSS 
was  envisioned  to  be  an  information  manager;  the  other  design  had  him 
as  a  master  console  operator.  Figures  2-2  and  2-3  represent  the  basic 
model  posed  for  information  flow  on  the  selected  van  layout. 


u  Ibid,  pp.  21-40. 
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The  last  example  is  an  analysis  undertaken  to  reduce 
operator  memory  load  and  improve  operator  effectiveness  by  providing 
extensive  cueing/prompting  to  reduce  the  complexity  of  operational 
procedures.  Honeywell  organized  all  of  the  functions  required  of 
SOTAS  into  a  heirarchial  tree  structure  that  clustered  conceptually 
related  functions  into  common  branches.  A  combination  of  functional 
keys  and  interactive  dialogues  were  recommended  for  gaining  access  to 
the  tree  structure  or  switching  heirarchy.  Functional  keys  were 
designed  to  provide  access  to  specific  branches  of  the  conceptual 
tree,  while  interactive  menus  were  designed  for  complex  branches  to 
provide  the  operator  with  a  set  of  options  to  guide  him  in  completing 
the  function.  The  system  will  be  interactive  and  tutorial  thus 
removing  the  memory  load  from  the  operator  and  transferring  it  to  the 
computer  system.  This  resulting  design  change  for  the  engineering 
development  model  has  the  additional  benefits  of  providing  immediate 
feedback  to  the  operator  regarding  the  appropriateness  of  his  action, 
reducing  the  complexity  of  initial  training,  reducing  the  requirement 
for  refresher  training,  and  reducing  the  skill  levels  required  to 
operate  the  system.  This  latter  benefit  should  help  resolve  the 
career  development  problem. 

The  three  examples  just  presented  were  chosen  for  their 
applicability  to  the  TOS  program,  as  will  be  discussed  below.  As  is 
evident  from  the  above  discussion,  use  of  human  resources  data  in  the 
SOTAS  program  has  been  continuous  from  the  onset.  The  emphasis  has 
changed  from  more  broad  general  objectives,  e.g.,  functional  analysis 
and  simulation  studies  to  narrower  specific  objectives,  e.g.,  the 
design  of  the  function  keyboard.  Now  that  an  engineering  development 
model  is  being  fabricated,  the  emphasis  has  switched  from  system 
design  considerations  to  training  and  doctrinal  employment  issues, 
although  the  former  are  still  being  addressed.  Figure  2-5  is  a 
recapitulation  provided  by  Honeywell  of  the  emphasis  on  human  factors 
during  the  past  five  years.  Most  of  the  current  emphasis  is  on 
secondary  ground  station  manning  requirements  and  the  continual 
refinement  of  training. 
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2.3 


XM1  ABRAMS  TANK  SYSTEM 


In  a  parallel  effort  to  this  contract,  SAI  conducted  a  case 
study  of  the  integration  of  personnel  and  training  subsystems  in  the 
XM1  Abrams  Tank  System.  This  subsection  discusses  some  selected 
topics  from  the  XMlQexperiences;  for  a  full  case  study,  see  the  XM1 
study  final  report. 

The  XM1  Abrams  Tank  System  is  significantly  different  from 
the  other  systems  reviewed  in  this  study  in  several 3critical  aspects. 
First,  XM1  is  a  weapons  system,  rather  than  a  (TI  system.  As  a 
weapons  system  its  role  on  the  battlefield  is  much  better  understood 
by  the  Army:  kill  and  survive  to  kill  again.  The  analysis  and 
determination  of  end  item  and  support  requirements  can  be  directly 
related  to  "bottom! ine“  measures  of  effectiveness:  lethality  and 
survivabil ity. 

Second,  XM1  is  a  replacement  system,  rather  than  a  new 
battlefield  concept.  While  XM1  is  a  significant  technological 
improvement  over  the  current  M60  Series  of  main  battle  tanks,  it  is  an 
improvement  of  degrees  rather  than  a  quantum  leap.  The  basic 
organizational  and  operational  concepts  of  the  tank  battalion  will  not 
undergo  major  changes  as  a  result  of  the  introduction  of  the  XM1  into 
the  inventory.  This  is  in  contrast  to  both  TOS  and  SOTAS  where  the 
details  of  the  system  mission  were  often  vague  and  changeable. 

Third,  XM1  was  from  its  inception  a  very  highly  visible 
acquisition  program.  Close  scrutiny  at  the  highest  levels  of  DA  and 
DoD  as  well  as  in  the  Congress  placed  the  system  developers  under 
unique  pressures  to  meet  cost  and  schedule  constraints. 

2.3.1  System  Description 

The  XM1  Abrams  Tanks  will  be  a  sophisticated,  highly 
reliable,  highly  mobile,  full-tracked  armor  fighting  vehicle 
incorporating  improvements  in  fire  control,  powerplant,  suspension 
system,  and  armor  protection.  It  will  consist  of  a  hull  and  a  turret 
(fighting  compartment)  designed  to  maximize  ease  of  operation  and  crew 
survivabil ity. 
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The  tank  will  be  operated  by  a  four-person  crew:  driver, 
gunner,  loader,  and  tank  commander,  all  trained  in  XMl-specific  MOSs. 
At  the  organizational  level,  the  tank  will  be  maintained  by  an 
automotive  repair  technician  (warrant  officer),  a  tactical 
communications  systems  mechanic,  a  chassis/system  mechanic,  and  a 
turret  mechanic,  the  latter  two  being  from  XMl-specific  MOSs.  At  the 
direct  support/general  support  (DS/GS)  level  the  XM1  will  be 
maintained  by  the  automotive  repair  technician  and  ten  enlisted  MOSs, 
half  of  which  have  XMl-specific  special  qualification  identifiers 
(SQI)  or  additional  skill  identifiers  (AS1). 

The  main  gun  is  stabilized  to  the  gunner's  sight  to  allow 
accurate  fi re-on- the-move  capability  at  relatively  high  cross-country 
speeds,  a  significant  improvement  over  the  current  M60A1A0S  and  M60A3 
tanks'  fire-on-the-move  capabilities.  At  the  same  time  it  poses 
additional  training  problems  for  the  gunner,  who  must  maintain  a 
stablized  sight  picture  while  turret  is  moving  about  him.  A  ballistic 
computer  system  automatically  solves  sight  parallax,  lead,  and 
superelevation  problems. 

The  designers  of  the  XM1  were  faced  with  the  dilemma  in  the 
weight/agility  trade-off.  The  greater  survivability  of  additional 
armor  carries  a  penalty  of  more  weight,  which  is  in  conflict  with  the 
goal  of  increasing  survivability  through  more  agility.  Not  only  is  a 
larger  engine  implied  by  heavier  armor,  it  is  also  implied  by  more 
agility.  However,  a  larger  engine  itself  means  more  weight,  which 
further  aggrevates  the  problem.  To  make  a  major  inroad  in  this 
constraint,  the  XM1  uses  a  gas  turbine  engine  which  can  produce 
considerable  saving  in  engine  weight  over  a  comparable  diesel  engine. 
Less  engine  weight  can  therefore  be  used  for  more  armor.  The  standard 
idle  allows  the  vehicle  to  move  at  a  creep  speed  of  2.5  miles  per  hour 
for  operations  with  dismounted  infantry  forces.  The  vehicle 
accelerates  to  twenty  miles  per  hour  in  6.2  seconds  from  idle  and  the 
maximum  vehicle  speed  is  governed  to  forty-five  miles  per  hour.  In 
spite  of  the  engine's  efficiency  relative  to  other  turbines  it  will 
use  six  to  twenty-five  percent  more  fuel  than  comparable  diesel 
engines.  A  bonus  of  the  turbine  is  its  relative  quiet  and  smokeless 
operation. 

The  suspension  system  features  seven  road  wheel  stations 
which  allows  each  wheel  to  have  a  smaller  diameter  thus  reducing  the 
vehicle  silhouette.  High  wheel  travel  gives  the  XM1  the  capability  to 
move  cross  country  at  high  speed  while  still  retaining  control  of  the 
tank  and  being  able  to  fire  the  gun. 


Perhaps  the  biggest  change  in  tank  technology  since  the  M60 
was  developed  is  the  area  of  armor.  The  Qualities  of  Special  Armor 
are  highly  classified,  however,  it  does  increase  the  resistance  to 
penetration.  Spaced  armor  is  also  used  in  several  places  to  protect 
key  components.  Compartmental ization  of  both  fuel  and  ammunition 
further  increases  crew  and  critical  components  survivability. 

.  The  training  device  requirements  of  the  XM1  were  approved  in 
late  1977  and  are  described  in  the  paragraphs  below.  Recent  changes 
to  some  support  equipment  concepts  will  lead  to  changes  as  yet 
undetermined  in  troubleshooting  training  reauirements  area. 

The  Conduct  of  Fire  Trainer  (COFT)  of  One-Station  Unit 
Training  (OSUT)  will  allow  one  instructor  to  teach  target  acquisition, 
identification,  and  engagement  to  ten  gunner  positions,  including  the 
visual  and  audio  feedback  of  the  fire  control  equipment.  Each  station 
is  individually  controlled  by  a  series  of  programs  of  varying 
difficulty  according  to  trainee  progress.  The  visual  simulation  is  to 
provide  a  target  scene  of  multiple  and  varied  targets,  as  well  as 
friendly  equipment,  with  appropriate  terrain  and  vegetation.  The 
visual  presentation  will  also  be  able  to  simulate  the  motion  of  the 
gunner's  tank  for  fi re-on- the-move  training. 

The  driver  trainer  will  allow  one  instructor  to  monitor  five 
students  at  stations  which  duplicate  the  driver's  compartment.  Visual 
and  audio  simulations  will  provide  the  students  "the  illusion  of 
driving  the  XM1  tank."  The  audio  and  visual  feedback  responds  to 
control  movements.  The  Unit  Conduct  of  Fire  Trainer  (U-COFT)  will  be 
a  shelter-mounted  simulator  to  provide  training  in  target  acquisition, 
identification,  and  engagement  with  either  primary  or  alternate  fire 
control  and  fighting  equipment  in  either  the  stabilized  or  the 
nonstabil ized  mode.  Student  actions  will  be  monitored  by  an 
instructor  station  which  replicates  the  students  visual  simulation  and 
which  can  insert  faults.  The  target  scene  will  have  the  same 
requirements  for  realistic  targets,  terrain,  and  vegetation  as 
OSUT-COFT. 

The  tank  turret  organi zational  maintenance  trainer  will 
facilitate  student  inspection,  troubleshooting,  installation,  and 
removal,  purging,  and  performance  of  proper  organizational  maintenance 
procedures,  as  contained  in  technical  publications.  The  trainer  will 
either  use  or  faithfully  simulate  turret  armaments,  fire  control 
systems,  turret  electrical  systems,  turret  hydrolic  systems  and 
controls,  elevating  and  traversing  systems,  stabilization  system. 


optics,  wiring  and  control  boxes,  and  intercoms  and  radios.  The 
trainer  will  allow  two  faults  to  be  simultaneously  inserted  which  can 
be  tested  and  corrected  using  the  test  equipment  and  tools  specified 
in  the  organizational  maintenance  manual.  Troubleshooting  simulators 
will  allow  the  instructor  to  demonstrate  and  for  the  student  to 
practice  troubleshooting  the  system.  They  include  actual  controls, 
fluid  flows,  electrical  current  flows,  and  auditory  cues  as 
appropriate  to  simulate  normal  operation  and  operation  with  easily 
inserted  faults.  Actual  or  simulated  diagnostic  equipment  provides 
readout  appropriate  to  either  normal  operation  or  the  simulated  fault. 
These  simulators  will  record  and  score  student  performance. 
Troubleshooting  simulators  will  be  provided  for:  X1100-3B  Transmission 
Hull  Electrical  SYstem,  Turbine  Engine,  Laser  Range  Finder,  Ballistic 
Computer,  Thermal  Site,  and  Direct  Support  (DS) /General  Support  (GS) 
Turret  Trainer. 

2.3.2  XM1:  Selected  HRD  Topics 

2. 3. 2.1  Human  Factors  Engineering  < HFE ) 

In  both  the  Advanced  Development  (AD)  and  Full  Scale 
Engineering  Development  (FSED)  phase,  responsibility  for  HFE  was 
vested  primarily  in  the  contractor  hardware  developers.  During  AD 
there  were  two  competing  contractors  (Chrysler  Corporation  and  General 
Motors  Corporation)  whose  plans  were  closely  guarded  as  proprietary; 
during  FSED  there  was  a  single  contractor  (Chrysler).  Little 
information  is  still  extant  concerning  the  AD  phase  HFE.  An  analysis 
by  HEL  and  the  US  Army  Medical  Research  and  Development  Command  (MRDC) 
provides  a  good  review  of  the  FSED  phase. 

Chrysler  created  an  HFE/System  Safety  (SS)  Group  to  monitor 
and  provide  guidance  for  the  HFE  program.  HEL  characterized  the 
HFE/SS  personnel  as  "highly  qualified  (both  academically  and 
experiential ly)  individuals  whose  combined  skills  have  been 
effectively  utilized  from  the  earliest  conceptual  stages  of  the 
XM1  program."  The  HFE  progr,ajn  iteself  was  described  as  "generally, 
comprehensive  and  effective." 


As  an  aid  to  the  design  engineers,  the  HFE/SS  Group  published 
an  HFE  and  safety  design  guide.  This  book  provided  a  convenient 
summary  of  HFE-related  requirements  and  criteria.  Its  purpose  was  to 
assist  in  producing  a  better  and  more  uniform  design  from  the  human 
factors  standpoint. 

HEL  noted,  however,  that  "there  were  a  few  areas  where  it 
appears,  that  HFE  considerations  which  significantly  affect  the 
operational  sui tatu.1  i ty  of  the  vehicle  were  overruled  by  cost 
reduction  changes."  They  also  noted  that  the  HFE/SS  group  had 
difficulty  in  gaining  access  to  a  mated  hull  and  turret  mock-up  and  to 
prototype  vehicles,  due  to  tight  work  schedules  and  cost  constraints. 
This  hampered  their  ability  to  gain  hands-on  experience  and  to 
demonstrate  some  man-machine  interfaces. 

The  HEL/MROC  report  was  prepared  to  support  the  ASARC  III 
decision.  A  list  of  topics  considered  is  shown  in  Figure  2-6. 

2. 3. 2. 2  Training  Device  Requirements  (TDRs) 

The  development  of  XM1  system  training  devices  was  delayed 
for  over  three  years  due  to  difficulties  in  defining  TDRs.  Two 
competing  training  device  concepts  were  considered.  One  called  for  an 
essentially  traditional  approach  to  armor  training,  emphasizing  the 
use  of  operational  equipment  and  relatively  low  development  and 
procurement  costs.  The  other  approach  would  employ  high  fidelity 
simulators  at  relatively  high  development  and  procurement  costs,  but 
held  out  the  possibility  of  lower  operating  and  support  costs. 

The  considerable  delay  in  establishing  TDRs  resulted  from  an 
inability  to  chose  between  the  two  approaches  in  an  objective  fashion. 
The  new,  high  technology  simulators  were  generally  still  in  the 
conceptual  design  phase,  and  thus  could  not  be  validated  by  empirical 
data. 
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Contractor  Program 

Program  Effectiveness 
Task  Analysis 

Environment  and  Environmental  Safety 
Noise 

Heating  and  Ventilation 
Toxicity 

Shock  and  Vibration 
Laser  Rangefinder  Safety 

Crew  Work  Space 

Ingress/Egress 
Geometry  and  Seating 
Control s/Displays 

Vision  and  Night  Operations 

Rearming 

Nuclear,  Biological,  and  Chemical  Survivability 
Crew  Maintenance 
Training  Analysis 


2-6.  TOPICS  CONSIDERED  BY  THE  HEL/MRDC  HFE  ANALYSIS 


The  major  analytic  effort  conducted  during  the  development  of 
the  TORs  was  a  Cost  and  Training  Effectiveness  Anlaysis  (CTEA)  of  the 
crew  training  devices  conducted  by  BDM  Services  Company  (BDMSC). 
This  study  contained  a  detailed  analysis  of  alternative  COFTs  and  a 
cursory  cost  analysis  of  a  Driver  Trainer  and  a  Full  Crew  Interaction 
Simulator.  No  analysis  was  conducted  of  any  training  devices  for 
maintainence. 

The  primary  analytical  tool  used  to  examine  training 
effectiveness  was  the  TRAINVICE  model,  ^iginally  developed  by  the 
American  Institutes  for  Research  for  ARI.vL  The  model  had  previously 
been  applied  to  two  non-system  devices157’  and  has  since  been 


y. 


applied  to  a  variety  xrf  programs, 
been  modified  by  ARI. 


The  model  has  since 


59,  60,  61,  62 


TRAINVICE  is  an  analytic  method  which  results  in  a 
quantitative  index  of  "training  transfer"  as  a  figure  of  merit.  The 
index  is  developed  through  analyses  of  the  coverage  of  critical  tasks, 
the  physical  and  functional  similarity  of  training  tasks  to 
operational  tasks,  and  the  appropriateness  of  the  learning  techniques 
applied.  The  TRAINVICE  index  provides  only  a  relative  figure  of 
merit,  i.e.,  while  it  is  useful  for  comparing  two  devices  to  one 
another,  it  provides  no  estimate  of  the  actual  training  impact. 

2. 3. 2. 3  Annual  Maintenance  Man  Hours  (AMMH) 

A  critical  data  input  to  the  QQPRI  is  the  AMMH,  from  which 
the  requirement  for  maintenance  personnel  are  determined.  The  XM1 
program  experienced  many  difficulties  in  establishing  AMMH  and  even 
now,  nearly  two  years  after  ASARC  III,  an  adequate  database  for 
determining  AMMH  is  lacking. 


59 
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(G/VLLD)  Cost  and  Training  Effectiveness  Analysis  (CTEA):  Phase  I 
Report,  Volume  I,  BDM/W-78-058-TR.  8DM  Corporation,  McLean,  VA:  13 
February  1978. 

60  R.W.  Swezey,  et.  al..  Implications  for  TOW  Gunnery  Training 
Developments.  Mellonics  Systems  Development  Division, 
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61  R.W.  Swezey,  et.  al..  Implications  for  Dragon  Gunnery  Training 
Developments.  Mellonics  Systems  Development  Division, 
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Fairly  early  in  the  program  it  was  determined  that  the 
appropriate  RAM  data.would  not  be  collected  during  DT/OT  I,  but  would 
wait  for  DT/OT  II.  As  an  interim  measure,  data  from  the  Army's 
field  experience  with  the  M60A1  and  M6QA2  and  projections  for  the 
M60A3  were  used. 

Plans  to  collect  AMMH  data  during  OT  II  went  awry  when 
problems,  developed  in  keeping  the  test  vehicles  running.  Hardware 
problems  resulted  in  major  modifications  to  the  end  item  during  the 
test  as  well  as  frequent  contractor  intervention  in  the  test 
maintenance.05  Data  was  also  collected  at  a  Physical  Teardown/ 
Maintenance  Evaluation  (PT/ME),  but  was  rejected  later  as 
unrepresentative.  In  an  attempt  to  develop  new  AMMH  for  ASARC  III,  PM 
XM1  convened  a  Maintenance  Data  Evaluation  Workshop,  which  employed  a 
Delphi  Approach.  The  Project  Management  Office  (PMO),  however, 
declared  that  there  were  too  many  problems  with  the  basic  data  and 
that  the  workshop  was  a  failure.  The  PMO  proposed: 

"It  is  recommended  that  consideration  be  given  to 
initially  fielding  the  XM1  using  current  TOE  [Table  of 
Organization  and  Equipment]  authorizations  for 
personnel.  After  a  period  of  field  experience,  AMMH 
could  then  be,computed  based  on  actual  data  and  used  to 
amend  TOE'S."6' 

A  final  QQPRI  was  not  approved  by  HQDA.  A  Final  MOS  Decision 
was  established  by  MILPERCEN,  but  with  a  proviso  that  an  Amended  Final 
MOS  Decision  would  be  required.  Data  to  determine  AMMH  is  now 
scheduled  to  be  collected  at  DT/OT  III. 


04  W.C.  Kietzman,  et.  al..  Developmental  Test  I  of  XM1  Tank  System 
(U ) :  Test  Plan  Final  Draft.  USATECOM,  Aberdeen  Proving  Ground, 
MD:  April  1975,  p.  3.  (SECRET) 

65  Logistics  Evaluation  Agency,  XM1  Tank  IIS  Program:  Interim 
Assessment.  New  Cumberland,  PA:  2  January  19/9. 

66  Msg.  15123(2  from  PMO  XM1  to  TSM  XM1,  ATZK-XM1 ,  dated  15  December 
1978.  Subject:  XM1  Logistic  Support  Analysis  Records  (LSAR) . 
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SECTION  III 


APPLICATION  OF  HUMAN  RESOURCES  DATA  IN  SYSTEM  DEVELOPMENT 


The  purpose  of  this  section  is  to  consider  the  range  of 
various  methods  which  have  been  used  in  incorporating  HRD 
considerations  into  system  development.  Among  those  issues  to  be 
examined  in  the  following  sections  are: 

•  How  are  HRD  defined? 

•  What  HRD  methodologies  are  most  useful  for  system 
development? 

•  At  what  phase  in  system  development  should  the 
various  HRD  elements  be  applied? 

•  How  can  the  use  of  HRD  tradeoff  analysis  during  the 
system  development  be  useful  for  human  engineering 
purposes? 

•  What  kinds  of  human  factors  testing  procedures  should 
be  employed  to  evaluate  system  design? 

t  What  needs  to  be  done  to  improve  the  feasibility  and 
effectiveness  of  HRD  utilization  in  system  design? 


3.1  DEFINITION  OF  HUMAN  RESOURCES  DATA 

During  the  initial  analysis,  it  became  apparent  that  human 
resources  data,  as  they  relate  to  this  effort,  are  not  wholly 
defined.  Terms  frequently  appearing  in  the  literature  relative  to 
human  resources  data  include:  human  engineering  data,  human  resources 
engineering,  and  human  factors  engineering  (HFE).  These  terms  are 
often  used  synonymously,  although  shades  of  difference  in  definition 
among  the  terms  appear  in  most  studies.  AR  602-1  provides  a 
definition  which  states  that  HFE  is  a  "comprehensive  technical  effort 
to  integrate  all  personnel  characteristics  (skills,  training 
implications,  behavioral  reactions,  human  performance,  anthropometric 
data  and  biomedical  factors)  into  Army  doctrine  and  systems  to  assure 


3-1 


■  .  •  .  i  . 


operational  effectiveness,  safety,  and  freedom  from  health  hazards. 
This  regulation  states  that  HFE  includes: 


•  That  part  of  system  analysis  that  determines  the 
personnel  role  in  a  personnel -materiel  system 

•  Selecting,  defining,  and  developing  personnel- 
materiel  interface  characteristics,  workspace  layout, 
and  work  environment  conducive  to  effective  and 
efficient  performance  under  expected  use  conditions 
{The  process  of  developing  and  defining  such  a  work 
environment  includes  a  detailed  analysis  of  the 
impact  of  the  proposed  environment  on  the  health  and 
well-being  of  operator  and  maintenance  personnel.) 

•  Coordination  with  other  agencies  in  determining  the 
needs  for  and  then  developing  and  evaluating  job 
procedures,  performance  aids,  and  training  devices, 
aids,  equipment,  and  technical  publications 

•  Providing  basic  personnel -materiel  task  sequence  data 
used  to  describe,  develop,  and  assess  the  feasibility 
of  the  soldier  performance  required  in  a  personnel - 
materiel  system 

•  Developing  equipment  which  permits  effective 
personnel -materiel  interaction  under  special 
limitations  in  the  training  time,  aptitudes,  skills, 
or  physical  standards 

•  Determining  the  number  and  kinds  of  military  and 
civilian  personnel  needed  in  a  personnel -materiel 
system  to  evaluate  the  relative  effectiveness  of 
design  concepts  and  for  subsequent  personnel 
planning,  and  providing  the  data  needed  for  modifying 
current  MOSs  or  establishing  new  MOSs  required  by  new 
equipment,  doctrine,  or  organization 


^ AR  602-1,  Personnel -Materiel  Systems  Human  Factors  Engineering 
Program,  June  1,  1976. 
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•  Assessing  the  training  burden  which  competing 
materiel  design  concepts  may  impose  on  the  Army 

•  Developing  the  information  needed  for  new  or  revised 
training  plans,  courses,  or  programs  of  instructions 
as  required  by  new  or  modified  materiel,  doctrine,  or 
organization 

•  Confirming  the  effectiveness  of  the  program  by 
evaluating  the  completed  personnel -materiel  system 

•  Conducting  research  required  to  resolve  personnel 
related  problems  encountered  in  materiel  development 
programs,  as  disclosed  through  systems  analysis  in 
the  first  bullet  above. 

The  regulation  goes  on  to  define  the  objectives  of  the  HFE 
as  follows: 

•  Assure  that  Army  materiel  and  concepts  of  its  use 
conform  with  the  capabilities  and  limitations  of  the 
fully  equipped  soldier  to  operate,  maintain,  supply, 
and  transport  the  materiel  in  its  operations 
environment,  consistent  with  tactical  requirements 
and  logistic  capabilities 

•  Insure  that  materiel  is  developed  so  that  the 
personnel  tasks  involved  in  its  operation, 
maintenance,  supply,  and  transport  do  not  exceed  the 
capabilities  of  the  soldier 

•  Assist  the  Army  trainer  in  achieving  an  effective, 
sufficient,  necessary,  and  integrated  Army  training 
program 

•  Improve  control  of  total  life  cycle  costs  of 
personnel -materiel  systems  by  assuring  consideration 
of  the  costs  of  personnel  resources  and  training  for 
alternative  systems  during  the  conceptual  stages  and 
for  the  selected  system  during  subsequent  stages 

•  Optimize  the  relationship  between  skill  levels, 
training,  and  personnel  required  to  operate  and 
maintain 
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•  Assure  that  equipment  designs  are  compatible  with  the 
capabilities  and  limitations  of  the  personnel  who 
must  operate  and  maintain  them  through  basic  and 
applied  studies  and  research,  personnel-materiel 

system  analysis,  and  psychophysiology  • 

•  Develop  data  defining  the  existing  range  of  human 
performance,  comparing  them  against  systems 
performance  requirements,  to  identify  new  performance 
requirements,  and  provide  for  the  timely  development 
of  the  necessary  trained  personnel  resources 

•  Insure  that  systems  engineering  considers  safety  and 
health  standards 

•  Provide  data  for  the  development  of  technical 
manuals,  training  manuals*  field  manuals,  and  other 
technical  publications  and  insure  that  the  use  of 
these  publications  does  not  require  aptitudes, 
education,  or  training  beyond  that  required  to 
perform  the  tasks  they  describe 

•  Apply  human  factors  engineering  concepts  and  current 
educational  technology  to  design  and  development  of 
training  devices  and  aids. 

From  another  perspective,  Prokuski  defines  human  factors 
engineering  as  a  concept  consisting  of  a  "systematic  and  integrated 
approach  to  providing  timely  products  and  processes  necessary  for 
optimizing  the  man-machine  relationship.  In  military  applications, 

Prokuski  applies  the  term  to  those  "engineering  and  myagement  tasks 
required  to  provide  for  effective  human  performance...” 


- - 

Bronislaw  Prokuski,  Human  Factors  Engineering  in  Air  Force  Weapon 
Systems  Acquisition,  Program  Management  Course  Individual  Study 
Program,  Defense  Systems  Management  College,  Study  Project  Report 
PMC  77-1,  May  1977,  p.  5-6. 

Prokuski,  op.  clt. ,  p.  5-9. 
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A  more  generic  definition  for  human  resources  provided  by 
Askren  suggests  that  "...human  resources  may  be  likened  to  the  other 
resources  of  the  organization  such  as  equipment,  facilities,  land,  raw 
material,  etc.,  which  can  be  drawn  upon  to  accomplish  the  purpose  of 
the  organization. ..human  resources  data. ..are  those  data  which 
describe  the  people  of  an  organization  in  terms  of  what  they  can 
contribute,  how  much  they  cost,  how  available  they  are,  how  perishable 
they  are,  and  how  many  of  them  are  needed." 

Using  Prokuski's  approach,  five  basic  elements  of  human 
resources  data,  were  identified: 

•  Manpower  and  personnel  requirements 

•  Biomedical 

•  Maintenance 

•  Training 


•  Human  factors  test  and  evaluation. 

These  elements  require  emphasis  by  both  engineering  and  management 
disciplines  and  suggest  that  a  complete  set  of  human  resources  data 
must  include  man's  function  in  the  system.  More  specifically,  each  of 
these  elements  can  be  operationally  defined  as: 

•  The  manpower  and  personnel  requirements  element  i s 
concerned  with  the  number  of  trained  personnel 
required  to  operate,  maintain,  control ,  and  support 
the  system  equipment  in  its  operational  environment. 

•  The  biomedical  element  includes  areas  which  require 
provisions  for  the  promotion  of  health  and  safety  of 
all  personnel  who  operate  and/or  maintain  the  system 
equipment. 


-K - 

William  B.  Askren,  Human  Resources  and  Personnel  Cost  Data  in 
System  Design  Tradeoffs:  And  How  to  Increase  Design  Engineer  Use 
of  Human  Data,  Technical  Report-AFHRL-TR-73-4fi.  Air  force  Human 
Resources  Laboratory:  October,  1973,  pp.  5-6. 


•  The  maintenance  element  is  concerned  with  predicting 
manpower  requirements  during  system  development. 
Methods  used  should  consider  maintenance  task  data  to 
provide  early  estimates  of  manpower  requirements  for 
use  in  making  system  tradeoffs. 

•  The  training  element  includes  all  training  supplied 
to  personnel  who  operate  and  maintain  the  system. 
This  element  has  four  subelements:  system  trained 
personnel  requirements,  training  plan,  training 
equipment  development,  training  support  data. 


•  The  human  factors  test  and  evaluation  element  should 
determine  whether  personnel wiHth  system  training  and 
system  peculiar  tools  can  operate,  maintain,  control, 
and  support  the  system  in  its  intended  operational 
environment. 

Based  on  these  considerations,  human  resources  data  can  be 
defined  as  that  human  engineering,  human  factors,  and  human  resources 
information  which  is  used  at  various  stages  of  the  system  acquisition 
cycle  to  insure  the  optimum  interface  between  system  hardware,  soft¬ 
ware,  and  personnel.  Human  resources  data  includes  all  engineering 
and  human  support  technologies  that  must  be  used  to  make  certain  that 
a  system  is  optimally  operated  and  maintained  In  tactical  environ¬ 
ments.  Proper  use  of  these  data  should  include  a  concern  for  “what 
data"  is  used  "when  in  the  system  acquisition  cycle,"  to  "what  extent" 
is  it  used,  "what  role"  it  plays  in  system  design  and  development,  and 
"how  much"  management  emphasis/priority  is  placed  on  its  use. 
Priorities  should  place  emphasis  on  designing  systems  with  proper 
consideration  for  human  functions  and  roles--rather  than  engineering 
systems  first  and  then  attempting  to  make  humans  fit  the  system. 

After  focusing  on  each  separate  HRD  element  and  available 
methods  which  apply  these  elements  to  system  development,  this  section 
will  investigate  existing  technologies  which  seek  to  integrate 
manpower,  biomedical,  maintenance,  and  training  HRD  elements.  An 
integrated  systems  technology  must  consider  all  HRD  elements  in  the 
optimal  unification  of  hardware,  software,  and  personnel. 

Conclusions  regarding  the  impact  of  HRD  methodologies  in 
system  development  will  be  made  indicating  technological  areas  which 
need  to  be  improved  upon  or  further  developed  to  increase  the 
feasibility  and  effectiveness  of  applying  HRD  in  the  system 
development  process. 


O  c. 


Although  it  is  not  the  purpose  of  this  section  to  provide  an 
in-depth  discussion  of  methods  of  deriving  HRD,  the  basic  principles 
involved  should  be  discussed  since  they  serve  to  identify  the  type  of 
HRD  to  be  considered  in  the  designing  of  systems. 

Systems  analyses  can  be  described  as  having  the  following 
general  purposes  (Kidd  and  Van  Cott,  1972). 

1.  To  identify  all  of  the  system  requirements  and  the 
logical  and  sequential  order  in  which  they  must  be 
accompl i shed 

2.  Identify  limiting  factors  which  serve  as  potential 
constraints  including  environmental,  hardware, 
information  acquisition,  flow  factors,  personnel 
problems,  and  costs 

3.  To  establish  system  performance  criteria  to  serve  as 
standards  for  both  designing  and  testing  the  system 

4.  To  identify  and  explicate  design  options  enabling 
the  designer  to  decide  on  man/machine  utilization 

5.  To  select  system  and  subsystem  performance  measures 
prerequisite  to  the  test  and  evaluation  of  the 
systems . 

Successfully  integrating  HRD  concerns  throughout  the  stages 
of  system  development  will  assist  in  the  designing  of  an  environment 
and  man-machine  interface  which  contribute  to  man's  successful  and 
efficient  performance  within  the  system. 

An  analysis  of  system  functions  serves  to  define  all 
operations  or  activities  which  contribute  to  the  system's  goal  or 
mission.  One  level  of  analysis,  the  functional  analysis,  serves  to 
determine  gross  system  functions  on  the  basis  of  system  requirements. 
The  purpose  of  the  functional  analysis  is  to  examine  possible 
alternative  combinations  of  functions  which  contribute  to  the 
successful  completion  of  the  mission. 


Jerry  S.  Kidd  and  Harold  P.  Van  Cott,  "System  and  Human  Engineering 
Analyses,"  in  Human  Engineering  Guide  to  Equipment  Design,  Harold 
P.  Van  Cott  and  Robert  G.  Kinkade,  tds.  US  Government  Printing 
Office:  Washington,  DC,  1972. 
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At  a  finer  level  of  detail,  the  task  analysis  specifies  the 
nature  of  performance  required  of  human  operators.  This  analysis 
results  in  information  concerning  stimulus  and  response  behavior  and 
the  prerequisite  skills  and  knowledges  necessary  for  successful  task 
completion.  Several  extensions  of  task  analysis  include  time-line 
analysis  and  sequential  analysis.  Time-line  analysis  provides 
information  regarding  periods  of  peak  personnel  and  equipment 
workloads  and  situations  resulting  in  conflicting  demands  upon 
personnel  or  equipment.  Sequential  analysis  is  useful  in  delineating 
the  sequential  distribution  of  operations,  tracing  the  information 
flow,  and  providing  indications  of  the  functional  relationships 
between  system  elements. 

Various  methods  of  system  analysis  can  serve  to  identify  both 
qualitative  and  quantitative  HRD  considerations  impacting  on  man's 
performance  in  the  system. 

3.2  MANPOWER  AND  PERSONNEL 

In  designing  systems  which  consider  manpower  and  personnel 
HRD,  the  first  step  is  the  projection  of  manpower  requirements.  The 
projection  of  manpower  requirements  is  initiated  with  the  allocation 
of  man/machine  functions.  Before  an  assessment  can  be  made  of  the 
skills  and  abilities  required  of  persons  who  operate  and  maintain  the 
system,  decisions  must  be  made  regarding  which  functions  will  be 
performed  by  men  and  which  will  be  performed  by  machines.  Chapanis 
(1965)°  proposes  a  strategy  for  making  man/machine  functional 
allocations.  His  approach  is  outlined  as  follows: 

1)  Prepare  a  complete  and  detailed  system 

2)  Analyze  and  list  system  functions 

3)  Make  tentative  assignments  for  each  function 

4)  Evaluate  the  sum  total  of  functions  which  have  been 
assigned  to  man. 


T 


Alphonse  Chapanis,  "On  the  Allocation  of  functions  between  men  and 
machines,"  Occupational  Psychology,  1965,  39  (1),  p.  1-11. 


Table  3-1  (Chapanis,  1965)^  lists  relative  capabilities  of 
men  and  machines. 

In  a  study  related  to  ±he  manpower  and  pesonnel  dimension  of 
HRD,  Meister  et  al.'s  (1969)®  research  for  the  Air  Force  Human 
Resources  Laboratory  sought  to  determine  what  differential  effects 
occur  as  a  result  of  applying  different  amounts  of  HRD  during  various 
times  over  the  systems  development  cycle.  The  main  purpose  of  the 
research  was  to  study  the  effects  upon  system  design  when  personnel 
quantity  and  quality  requirements  are  varied.  The  experiment  was 
designed  to  analyze  these  two  parameters  utilizing  eight  design 
engineers  as  subjects  for  the  study.  Conditions  of  the  experiment 
included  a  number  of  engineering  design  solutions  as  a  function  of  the 
HRD  input  at  various  times  during  system  design;  i.e.,  the  study 
sought  to  determine  whether  the  time  of  HRD  inputs  made  any 
differences  relative  to  system  design  options. 


In  this  study  the  authors  noted  that  HRD  manpower 
requirements  should  have  a  direct  influence  on  system  design.  Meister 
defines  manpower  requirements  as  the  maximum  number  and  skill  levels 
of  personnel  for  whom  the  system  is  being  designed.  These 
considerations  should  require  the  systems  engineer  to  design  a  system 
that  would  meet  these  requirements.  The  supporting  data  necessary  for 


an  early  assessment  of  manpower  requirements  is  shown  in  Table  3-2. 
(Meister  et  al.,  1969 r 


The  results  of  this  study  suggested  that  the  amount  and 
timing  of  HRD  inputs  do  produce  some  impact  on  the  engineer's  design. 
Specifically,  various  personnel  requirement  constraints  affected 
design  decisions.  Additionally,  type  of  manpower  requirements 
constraints  versus  personnel  numbers  create  enlightened  attitudes 
toward  the  utilization  of  this  kind  of  data  in  the  system  design 
process.  The  most  significant  aspect  of  the  study,  from  the  HRD 
perspective,  was  that  if  HRD  are  to  be  used  in  the  system  design,  they 
must  be  introduced  during  the  initial  stages  of  design,  and  should  be 
written  as  design  requirements^ 


David  Meister,  Dennis  0.  Sullivan,  Dorothy  L.  Finley,  and  William 
B.  Askren.  The  Effect  of  Amount  and  Timing  of  Human  Resources  Data 
on  Subsystem  Design,  Technical  keport  tio.  AFHRL-TR-69-22.  Air  Force 
Human  Resources  Laboratory:  October  1969. 
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TABLE  3-1:  A  HIGHLY  ABBREVIATED  LIST  OF  SOME  OF  THE  RELATIVE 
ADVANTAGES  AND  DISADVANTAGES  OF  MEN  AND  MACHINE 


MEN 

Able  to  handle  low  probability 
alternatives,  i.e.,  unexpected 
events. 


Able  to  perceive,  i.e.,  to 
make  use  of  spatial  and 
temporal  redundancies  and 
so  to  organize  many  small 
bits  of  information  into 
meaningful  and  related 
"wholes." 

Possess  alternative  modes  of 
operation.  Can  accomplish 
same  or  similar  results  by 
alternative  means  if  primary 
means  fail  or  are  damaged. 

Limited  channel  capacity,  i.e., 
there  is  a  maximum  amount  of 
information  that  can  be 
handled  per  one  time,  and 
this  is  small. 

Performance  subject  to  detre- 
ment  over  fairly  short  time 
periods,  because  of  fatigue, 
boredom,  and  distraction. 

Comparatively  slow  and  poor 
computers . 

Flexible:  can  change  prog- 
gramning  easily  and 
frequently.  Very  large 
number  of  programs 
possible. 


MACHINES 

Difficult  to  program.  Diffi¬ 
cult  to  anticipate  all 
possible  events  and  so  virtu¬ 
ally  impossible  to  program 
for  all  such  contingencies. 

Zero,  or  very  limited,  ability 
to  perceive.  "Organization" 
has  to  be  elaborately  pro¬ 
grammed,  which  is  difficult  to 
do  because  of  the  many  alterna¬ 
tive  ways  organization  can  be 
formed  from  elements. 

Alternative  modes  of  operation 
limited.  May  break  down  com¬ 
pletely  when  partial  injury  or 
damage  occurs.  Not  able  to 
regenerate  or  heal. 

Channel  capacity  can  be  made 
almost  as  large  as  desired. 


Behavior  decrements  only  over 
relatively  long  periods  of 
time. 


Excellent  and  very  rapid 
computers . 

Relatively  inflexible.  Flex¬ 
ibility  in  kind  and  number 
of  programs  can  be  achieved 
only  at  a  great  price. 


C 
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TABLE  3-2 


LIST  AND  DEFINITION  OF 
HUMAN  RESOURCES  DATA  INPUTS 


I.  MANPOWER  REQUIREMENTS 


(1)  Number  of  personnel 


(2)  Skill  level 


Definition 

Quantity  of  personnel  required 
to  perform  subsystem  operations, 
defined  in  terms  of  maximum 
number  allowed. 

Skill  levels  allowed  for  the  task. 


II.  SUPPORT  DATA 


(1)  Lists  of  personnel  tasks 


(2)  Personnel /equipment  flow 


(3)  Personnel /equipment 
analyses 


(4)  QQPRI  Data  including: 
(a)  Proficiency 


(b)  Skill  type 


(c)  Personnel 
availability 


Definition 

Tasks  defined  in  terms  of  per¬ 
sonnel  functions  and  equipment 
acted  upon. 

Diagrams  illustrating  the 
sequencing  and  interrelationships 
among  tasks. 

Description  of  equipment  char¬ 
acteristics  required  by  tasks  or 
effect  of  equipment  character¬ 
istics  on  task  performance. 


Skill  characteristics  which 
personnel  should  possess  to 
perform  the  job  satisfactorily. 

Characteristics  of  the  job  to  be 
performed  in  terms  of  demands  upon 
personnel . 

Definitions  of  US  Air  Force 
Systems  Command  (AFSC)  type  pos¬ 
sessing  necessary  qualifications 
to  perform  the  job,  together  with 
the  probability  of  such  personnel 
being  available  for  the  job. 


'  V  '/  V  •• 
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TABLE  3-2  (Cont.) 


LIST  AND  DEFINITION  OF 
HUMAN  RESOURCES  DATA  INPUTS 


(5)  Training  requirements, 
including: 

(a)  Anticipated  training 
time 

(b)  Required  aptitude 

(6)  Task  analysis,  including: 

(a)  Task  structure 

(b)  Task  criticality 

(c)  Team  performance 

(d)  Probability  of  suc¬ 
cessful  task 

compl eti on 

(e)  Task  location 

(f)  Task  duration 

(g)  Difficulty  Index 

(7)  Time-line  analysis, 
including  task  frequency 


Time  needed  to  train  to  given 
level  of  proficiency. 

Job  skills  which  training  should 
provide. 


Task  description  in  terms  of 
function  and  equipment  operated  or 
maintained  (See  Item  II  (1)). 

Consequences  of  task  being 
performed  incorrectly  or  not  at 
all. 

Number  of  personnel  required  to 
perform  the  task. 

Quantitative  estimate  of  prob¬ 
ability  that  the  task  will  be 
completed  successfully  by  per¬ 
sonnel  (the  converse,  error 
probability,  also  is  provided). 

Approximate  physical  area  (e.g., 
flight  line,  shop)  in  which  the 
task  must  be  performed. 

Estimate  of  the  time  required  to 
perform  a  task. 

Estimated  difficulty  of  task 
defined  in  terms  of  error 
probability  and  response  time. 

Distribution  over  time,  including 
overlaps,  of  individual  task 
durations. 


Another  study  by  Eckstrand  (1972)*  examined  the 
effectiveness  of  using  manpower  and  personnel  resources  data  as  design 
requirements  and  determined  under  what  conditions  these  inputs  can 
have  maximum  influence  on  system  configuration.  Given  equipment 
specifications  and  hardware  information,  design  engineers  were  given  a 
manpower  constraint  which  required  them  not  to  exceed  a  certain  crew 
size  and.  skill  level.  They  were  also  given  HRD  inputs  such  as  task 
analyses,  training  requirements,  and  time-line  analyses.  Engineers 
were  asked  to  design  equipment  so  that  it  could  be  operated  and 
maintained  by  a  specific  number  and  type  of  personnel. 

It  was  found  that  HRD  inputs  must  be  supplied  to  the  engineer 
in  the  Statment  of  Work  (SOW),  and  must  be  understandable  in  terms  of 
the  design  implications  of  the  HRD  inputs.  It  was  concluded  that  HRD 
inputs  do  influence  system  design,  but  engineers  resist  the  concept 
that  HRD  analyses  are  a  part  of  the  control  subsystem  design. 

A  method  of  applying  manpower  and  personnel  HRD  data  that  has 
proven  effective  in  improving  development  decision  correctness  is  the 
use  of  HRD  handbooks.  Meister  ( 1976 ) 1 A  used  an  HRD  handbook  developed 
by  the  Air  Force  Human  Resources  Laboratory  which  included  manpower 
and  personnel  data  and  examined  the  effectiveness  of  the  handbook  to 
assist  users  in  solving  hypothetical  or  simulated  system  development 
problems.  The  results  of  this  study  indicated  that  systems  devel¬ 
opment  personnel  were  able  to  .use  the  HRD  handbook  to  improve  the 
correctness  of  their  development  decisions.  Respondents  generally 
felt  that  the  handbook  had  some  utility  in  influencing  design,  and 
Meister,  therefore,  recommended  further  development  of  HRD  handbooks 
as  a  design  tool  for  systems  engineers. 

Another  concern  regarding  the  incorporation  of  manpower  and 
personnel  HRD  in  system  development  is  to  ensure  the  proper  selection 
of  personnel  with  the  necessary  ability  to  be  able  to  operate  the 
system  effectively.  Valid  testing  and  evaluation  cannot  be  conducted 
unless  qualified  personnel  are  selected  to  man  the  system.  The  Army 
Classification  Battery  (ACB)  provides  measures  of  trainability  in 
MOSs.  The  most  basic  kinds  of  information  which  impact  on  decisions 
made  during  the  classification  process  are  the  aptitudes  and  abilities 


Gordon  A.  Eckstrand,  Human  Resources  Consideration  in  the 
Development  of  Complex  Systems,  Technical  Report--AFHRL-TR-72-64. 
Air  Force  Human  Resources  Laboratory:  September  1972. 

**  David  Meister,  Assessment  of  a  Prototype  Human  Resources  Data 
Handbook  for  Systems  Engineering,  Technical  Report, 
AFHkL-ik-/b-92.  Air  i-orce  Human  Resources  Laboratory:  December 
1976. 
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of  the  men  and  the  manpower  needs  of  the  Anny.  It  is  necessary  to 
match  the  aptitudes  and  abilities  of  the  available  manpower  to  meet 
the  manpower  needs  of  the  system.  Table  3.3  (Maier  and  Fuchs,  1972 ) 1 ^ 
shows  the  tests  which  form  the  aptitude  area  composites  for  the  ACB. 
Each  composite  includes  tests  which  measure  the  aptitudes  and 
abilities  important  for  a  particular  MOS.  The  ACB  provides 
information  about  aptitudes  and  abilities  and  the  Army  requirements 
are  determined  by  set  quotas  for  each  MOS.  The  capabilities  of  the 
individuals  are  matched  to  the  demands  of  the  MOS  so  that  the 
aptitudes  and  abilities  of  manpower  are  used  to  the  best  advantage. 

However,  when  considering  effective  manpower  utilization  in 
developing  systems,  it  may  be  necessary  to  reanalyze  existing  tests  to 
make  sure  that  they  are  selecting  the  most  qualified  personnel  to 
operate  the  system.  It  may  be  necessary  to  design  the  system  down  to 
meet  minimum  skill  level  requirements  based  on  manpower  availability 

constraints,  but  the  types  of  testing  used  in  the  selection  process 

should  be  valid  and  reliable  measures  of  abilities  required  of  system 
operators.  C are  should  be  taken  that  proper  specification  of  MOS  be 
made  in  assigning  personnel  to  test  the  operational  effectiveness  of 
newly  developed  systems.  New  aptitude  area  composites  or  MOSs  may 
need  to  be  developed  or  refined  to  more  accurately  describe  the 

ability  requirements  of  manpower  serving  the  system. 

In  summary,  methods  which  apply  manpower  and  personnel  HRD 
data  to  system  development  are  concerned  with  the  early  projection  of 
manpower  requi rements--speci f ically  numbers  and  skill  levels. 
Manpower  and  personnel  HRD  requirements  should  be  introduced  during 
the  initial  stages  of  system  design  to  have  maximum  influence  on 

system  configurations.  It  has  been  determined  that  the  use  of  HRD 
handbooks  can  serve  as  a  design  tool  for  system  engineers  and  improve 
the  correctness  of  system  development  decisions.  Personnel  must  be 
selected  with  the  necessary  skills  and  abilities  to  provide  valid 
tests  of  the  system's  operational  effectiveness. 
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TABLE  3-3 


NEW  APTITUDE  AREA  COMPOSITES 


TEST 

APTITUDE 

AREA 

COMPOSITES 

General  Ability  Tests 

CO 

FA 

EL  OF 

SC 

MM 

GM 

CL 

ST 

GT' 

Arithmetic  Reasoning 

<AR) 

AR 

AR 

AR 

AR 

AR 

AR 

AR 

AR 

General  Information 

(GI) 

GI 

GI 

MK 

Mathematics  Knowledge 

(MK) 

MK 

WK 

MK 

WK 

WK 

Word  Knowledge 

(WK) 

SK 

SK 

Science  Knowledge 

(SK) 

Mechanical  Ability  Tests 


Trade  Information 

(TI) 

TI  TI 

TI 

Electronics  Information 

(El) 

El  El 

El 

Mechanical  Comprehension 

(MC) 

MC 

MC 

Automotive  Information 

(AI) 

AI 

AI 

Perceptual  Ability 


Pattern  Analysis 

(PA)  PA 

PA 

Attention-to-Detail 

(AD)  AD 

AP 

Auditory  Perception 

(AP). 

Classification  Inventory 


Combat  Scale 
Attentiveness  Scale 
Electronics  Scale 
Maintenance  Scale 


(CC)  CC 

(CA)  CA  CA  CA 

(CE)  CE 

(CM)  CM 


Symbols:  Aptitude  Area  Composites 


CO  *  Combat 

FA  =  Field  Artillery 

EL  =  Electronics  Repair 

OF  =  Operators  and  Food 

SC  ■  Surveillance  and  Communications 


MM  =  Mechanical  Maintenance 
GM  =  General  Maintenance 
CL  *  Clerical 
ST  =  Skilled  Technical 


8  GT  used  only  to  determine  who  is  qualified  to  take  additional 
tests  such  as  the  Officer  Candidate  Test. 


3.3. 


BIOMEDICAL 


In  examining  methods  of  applying  biomedical  HRD,  all  sub¬ 
systems  must  be  examined  to  identify  sources  of  hazard  which  would 
adversely  effect  the  health  anrL  safety  of  personnel.  A  study 
conducted  by  HEL  and  MRDC  (1979) 1,5  used  a  Human  Factors  Engineering 
Analysis  (HFEA)  in  support  of  the  XM1  ASARC  III  in  order  to: 

•  Identify  those  areas  where  the  man-machine  interface 
is  limiting  overall  system  performance 

•  Identify  vehicle  characteristics  which  may  prove  to 
be  physiologically  harmful  to  the  crew 

•  Recommend  corrective  actions  or  further  investiga¬ 
tions  where  appropriate. 

This  research  was  conducted  jointly  by  HEL  and  MRDC,  with  the 
assistance  of  the  Army  Health  Services  Command  (HSC).  A  complete 
analysis  and  recommendations  are  provided  in  areas  of  environment  and 
environmental  safety;  crew  work  space;  vision  and  night  operations; 
rearming;  nuclear,  biological,  and  chemical  (NBC)  survivability;  crew 
maintenance;  and  training  devices.  Each  system  entity  impacting  on 
operator  health  and  safety  was  analyzed  in  accordance  with  structured 
military  requirements  designed  to  fulfill  program  objectives.  An 
analysis  was  conducted  to  ensure  adequate  consideration  of  HFE  factors 
in  the  numerous  trade-offs  which  need  to  be  made  in  the  design  of  the 
combat  vehicle.  For  example,  one  of  the  recommendations  resulting 
from  the  noise  analysis  was  to  specify  by  means  of  warning  placards 
that  protective  hearing  gear  be  worn  whenever  the  vehicle  is 
operating.  In  order  to  provide  an  organizing  framework  to  assist  the 
human  factors  engineer,  a  Human  Factor  Engineering  and  Safety  Design 
Guide  was  publ i shed  to  summarize  all  the  human  /actors  engineering  and 
system- related  design  requirements. 

Various  methods  are  available  to  examine  the  impact  of 
applying  human  factors  data  in  the  designing  of  equipment  and  crew 
workspace.  It  is  unfortunate  that  these  human  factors  considerations 
are  frequently  not  considered  early  enough  to  have  maximum  impact  on 


^  HEL/MRDC,  Human  Factors  Engineering  Analysis  for  XM1  System  ASARC 
III .  Aberdeen  Proving  Ground,  MD:  January,  1979. 


system  design.  Meister  et  al's  (1969)*  study  determined  that  among 
various  types  of  HRD  inputs  considered  during  predesign  and  detailed 
design  states,  the  designing  of  equipment  required  by  personnel 
characteristics  or  tasks  was  a  low  priority  HRD  input. 

The  Human  Engineering  Guide  To  Equipment  Design  sponsored  by 
the  Joint  Army-Navy-Air  l-orce  bteering  committee  TVan  Cott  and 
Kinkade,  1972}  discusses  the  proper  design  of  controls,  individual 
workplaces,  and  mul ti -man-machine  work  areas  in  order  to  encourage  and 
preserve  the  user's  physiological  health.  This  involves  considering 
problems  and  constraints  resulting  from  physical  and  behavioral 
variations  among  men  and  the  structural  and  functional  limitations  of 
man.  The  information  presented  in  this  guide  is  of  use  in  the 
application  of  biomedical  types  of  HRD  during  system  development. 

Numerous  studies  have  been  devoted  to  examining  the  stresses 
effecting  soldiers  in  combat.  A  literature  review  intended  to  relate 
stressors  associated  with  continuous  Army  operations  with  human 
performance  was  conducted  by  Pfeiffer  and  Associates  (1979). 
Variables  such  as  vision,  hearing,  strength,  sleep  loss,  heat,  cold 
communications,  etc.  and  their  effects  on  performance  are  discussed. 
A  taxonomy  of  performance  abilities  is  provided  in  the  report  and  a 
description  of  those  factors  or  conditions  unique  to  continuous 
operations.  A  list  of  tasks  critical  to  the  attainment  of  specific 
mission  goals  was  formulated  for  each  of  the  five  members  of  a 
mechanized  infantry  fightinq  squad  and  categorized  according  to  the 
ability  taxonomy.  A  comparison  volume  serves  as  a  guidebook  which 
identifies  performance  limitations  on  the  basis  of  relationship 
between  impacting  variables  and  the  performance  taxonomy.  Table  3-4 
(Pfeiffer  et  al.,  1979)  shows  the  type  of  data  generated  from  the 
literature  review,  pertaining  to  performance  documents  in  various 
environmental  conditions. 

Pfeiffer  also  discusses  the  problems  asociated  with  deriving 
biomedical  HRD  and  distinguishes  between  the  psychological  and 
physiological  limits  of  toleration  to  stress.  He  defines  the 


- - 

Meister,  Sullivan,  et  al ,  op.  cit. 

Mark  6.  Kubala,  Arthur  I.  Siegel,  Stanley  E.  Taylor,  and 
Lucius  Shuler,  Jr.  Background  Data  for  the  Human  Performance  in 
Continuous  Operations  Guidelines,  Technical  Report  386.  Army 
Research  Institute,  Alexandria,  VA:  July  1979. 


psychological  limit  as  being  the  level  beyond  which  performance  is 
unsatisfactory;  stress  exceeding  physiological  limits  would  cause 
irreparable  tissue  damage.  Systems  should  be  designed  and  mission 
goals  established  which  do  not  result  in  permanent  negative  conse¬ 
quences  to  the  soldier's  health  by  exposure  to  severe  environmental 
stressors.  Research  designed  to  measure  physiological  and  psycho¬ 
logical  limits  is  difficult  because  of  the  dangers  of  inflicting 
permanent  tissue  damage  on  experimental  subjects.  Research  conducted 
on  animals  when  generalized  to  the  human  populus  does  not  permit 
accurate  specification  of  tolerance  limits.  Requirements  for  the 
design  of  experimental  research  relating  to  human  ability  and 
environmental  stress  include: 

•  different  levels  of  exposure  to  environmental  stress 
for  different  time  periods 

•  determining  the  response  of  the  subject  to 
environmental  stress  • 

•  determining  responses  of  each  subsystem  of  the 
organism  to  severe  environmental  stress. 


“Since  data  are  both  lacking  and  difficult  to  obtain  near  the 
upper  limits  of  human  tolerance,  modeling  techniques  and  computer 
simulation  may  be  required  to  predict  the.,effect  of  severe 
environments  on  performance  (Pfeiffer,  1979). "i/  A  multitude  of 
stressors— both  psychological  and  physiological --confront  the  soldier 
in  combat.  Existing  research  on  the  performance  effects  of  stress 
have  been  minimal,  and  existing  research  findings  conflicting  (Kubala, 
1979).  Much  of  the  available  research  is  not  relevant  to  the  combat 
situation.  There  is  a  need  for  further  studies  which  examine  the 
interactions  among  stressors;  for  example,  it  is  possible  that 
additive  and  subtractive  effects  occur  causing  two  or  more  environ¬ 
mental  stressors  to  combine  to  cancel  each  other  out  or  enhance  each 
other.  Until  improved  methods  are  derived  for  generating  this  type  of 
HRD  and  more  conclusive  evidence  is  gathered,  these  concerns  will  not 
have  a  heavy  influence  in  system  design. 


^  Ibid. 
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MAINTENANCE 


The  rising  maintenance  costs  and  emphasis  on  increased 
availability  of  Naval  air  systems  led  Baumgartner  (1977)iy  to  conduct 
a  study  of  the  human  factors  engineering  as  a  design  parameter  leading 
to  improved  aircraft  maintainability.  One  of  the  major  results  of 
this  study  was  a  check  list  developed  by  Baumgartner  to  be  used  by 
aircraft  designers  and  Navy  design  monitors  to  ensure  that  human 
factors  data  had  been  utilized  and  applied  to  the  design  of  aircraft 
in  order  to  improve  the  maintainability  of  their  subsystems.  When 
properly  used,  this  check  list  was  also  designed  to  indicate  potential 
design  deficiencies  during  initial  development  stages  relative  to 
maintenance  personnel  being  able  to  perform  maintenance  tasks  more 
efficiently  and  effectively.  Timely  use  of  human  factor  engineering 
data,  it  was  concluded,  allows  for  engineering  changes  to  be  more 
easily  made. 

A  method  of  predicting  and  demonstrating  the  system  effec¬ 
tiveness  parameters  of  combined  man-machine  systems  was  developed  by 
the  Na>vy.  The  Human  Reliability  Prediction  System  User's  Manual 
(1977)^  was  developed  to  predict  such  parameters  as  system  mission 
reliability  and  availability,  and  design  oriented  measures  such  as 
human  and  equipment  mean-time-between-fail ure  (MTBF).  Simple 
log-normal  prediction  models  used  to  estimate  maintainabil  ity 
parameters  are  presented  in  the  user's  manual.  These  include: 

•  Maintenance  power  (repair  time  as  a  function  of 
manhours  and  experience) 

a  Distribution  of  repair  time  per  repair,  a  function  of 
average  repair  crew  experience 

•  Distribution  ov  man-hours  per  repair  as  a  function  of 
average  repair  crew  experience 

a  Number  of  repairmen  per  repair 


Human  Reliability  Prediction  System  User's  Manual .  Department  of 
the  Navy,  Sea  Systems  Command,  December  1977. 


•  Repair  crew  experience 

•  Annual  man-hours 

t  Average  number  of  repairmen  appearing  within  each 
experience  category. 

Another  technique  which  can  be  used  in  the  application  of 
maintenance  HRD  is  using  correlational  models  to  express  the 
interrelationship  of  subsystem  design,  maintenance^skill  requirements, 
and  resulting  job  performance.  (Eckstrand,  1972F1  The  use  of  such 
correlational  models  would  make  it  possible  to  predict  the  impact  of 
alternative  equipment  designs  on  training  requirements.  As  a  result 
tradeoffs  could  be  made  to  determine  the  best  balance  between  hardware 
capabilities  and  maintenance  support.  A  variety  of  questionnaires, 
checklists  and  rating  scales  can  be  developed  to  obtain  information 
concerning  system  maintenance  and  skills  of  personnel. 

These  correlational  models  help  determine  how  aptitude, 
technical  training,  and  subsystem  design  influence  maintenance 
performance.  This  information  can  be  used  by  engineers  to  adjust  the 
skill  levels  required  of  maintenance  personnel  to  obtain  optimal 
output  in  terms  of  maintenance  time  and  system  reliability.  If  the 
required  skill  levels  are  considered  unrealistic  or  unacceptable,  the 
engineer  can  adjust  his  design  accordingly.  This  methodology  can 
prove  useful  in  improving  the  quality  of  Input  data  in  simulation 
models  by  giving  the  model  a  capability  of  dealing  with  skill  level. 

The  use  of  computer  simulation  models  may  prove  useful  in 
estimating  maintenance  manpower  requirements.  Computer  simulations 
can  be  used  to  simulate  break  downs,  repairs,  and  manpower  utilization 
enabling  system  engineers  to  consider  HRD  Impacts  and  alternatives 
before  the  system  is  designed  and  developed.  Maintenance  Manpower 
Modeling  (MMM)  is  a  model  which  has  to  be  used  to  estimate  maintenance 
manpower  requirements  for  new  systems  and  evaluate  the  effects  of 
certain  system-level  tradeoffs.  This  model  has  been  successfully 
applied  to  several  different  aircraft  systems  providing  early 
estimates  of  maintenance  task  data.  Comparability  analyses  serve  to 
examine  maintenance  requirements  of  comparable  subsystems  and 


7T 


Eckstrand,  0£.  cit. 


3-21 


equipment  on  existing  aircraft.  A  flow  diagram  for  the  MMM  is  shown 
in  Figure  3-1  (Goclowski  et  al ,  1978). 

The  data  obtained  through  the  comparability  analysis  are 
combined  with  a  detailed  operations  scenario  and  support  concept 
assumptions  leading  to  the  development  of  a  simulation  program.  The 
Logistics  Composite  Model  (LCOM)  simulates  the  maintenance 
requirements  of  the  new  weapon  system  providing  such  information  as 
time  span  between  maintenance  actions,  task  sequencing,  task  time, 
maintenance  crew  sizes  and  composition,  etc. 

A  problem  arising  from  the  use  of  comparability  analysis  is 
the  lack  of  reliability  among  source  data.  Tetmeyer  et  al .  (1976pJ 
in  a  report  to  the  Air  Force  Human  Resources  Laboratory  found  that 
consistent  and  significant  differences  between  data  on  the  same 
aircraft  and  for  the  same  equipment  installed  In  different  aircraft 
resulted  in  the  use  of  unreliable  Input  data  causing  reduced  output 
reliability. 

The  use  of  factor  analytic  methods  to  derive  tests  which 
measure  maintainability  has  proven  to  have  predictive  validity. 
Topmiller  (1964)^  Investigated  the  predictive  validity  of  human 
engineering  recommendations  included  in  maintainability  design  guides. 
A  checklist  was  developed  for  each  subsystem  design  feature  of 
selected  Air  Force  weapon  systems.  The  checklist  presented  choices 
among  alternatives  ranging  from  "The  feature  is  clearly  a  design 
characteristic  of  the  equipment"  to  "The  feature  Is  not  possessed  by 
the  equipment."  The  data  derived  from  scoring  the  checklist  was 
compared  with  mean  maintenance  times  derived  from  standard  Air  Force 
maintenance  data  reports  to  evaluate  its  predictive  validity. 


John  C.  Goclowski,  Gerard  F.  King,  Paul  G.  Ronco,  and  William  B. 
Askren,  Integration  and  Application  of  Human  Resource  Technologies 
In  Weapon  System  Design:  Coordination  of  Five  Human  Resource 
Technologies,  AFHkL-TR-78-bU).  Air  Force  Human  Resources 
Laboratory:  March  1978.  (See  also,  AFHRL-TR-78-6  (111),  May  1978) 
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D.A.  Topmiller,  A  Factor  Analytic  Approach  to  Human  Engineering 
Analysis  and  Prediction  ot  system  Maintainability,  Report  no. 
aFrl-Yr-64-11$.  Aerospace  Medical  Research  Labs.,  WPAFB,  Ohio: 


Seven  factors  were  identified  which  significantly  correlated 
with  the  maintainability  criterion.  These  factors  formed  seven 
subtests  which  include  maintenance  safety,  maintenance  information, 
fasteners  and  tools,  alignment  and  keying,  manual  control  layout, 
workspace  configuration,  and  accessibility.  These  sub tests  can  be  used 
by  human  engineers  to  project  maintenance  manpower  requirements  and  to 
indicate  the  extent  to  which  a  particular  design  will  meet  maintain- 
ab i 1 i ty  requ i remen ts . 

3.5  TRAINING 

The  application  of  HRD  during  system  development  to  influence 
the  early  projection  of  training  requirements  can  be  accomplished  by 
considering  five  areas  of  training.  These  include: 

•  System  trained  personnel  requirements 

•  Training  plan 

•  Training  equipment  development 

•  Training  facilities 

•  Training  support  data. 

The  Instructional  System  Development  (ISD)  model  is  designed 
for  the  development  and  accomplishment  of  education  and  training 
programs  in  the  military.  5  The  JJSD  decision  process  is  shown  in 
Figure  3-2  (Goclowski  et  al ,  1978). 

ISD  is  used  to  design  new  instructional  systems  and  improve 
upon  existing  systems.  A  task  analysis  is  conducted  to  determine  if 
new  training  programs  are  necessary  and  what  type  of  courses  are 
required  to  administer  training.  A  basic  objective  of  ISD  is  to 
facilitate  and  encourage  interservice  training  in  all  those  situations 
which  meet  the  established  criteria.  They  are  designed  to  eliminate 
the  possibility  of  unnecessary  duplication  of  training  programs  and  to 
take  advantage  of  prior  work  done  in  developing  training  courses 


Headquarters,  TRADOC,  Interservice  Procedures  for  Instructional 
Systems  Development,  TRADOC  Pamphlet  3bO-3U.  Fort  Monroe,  Va: 
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within  the  services.  This  is  a  useful  method  of  developing  inputs  to 
training  requirements  during  system  development.  The  human  engineer 
can  be  presented  information  in  the  form  of  existing  job  analysis 
surveys  and,  if  these  sources  are  similar  to  those  tasks  for  which 
current  training  needs  exist,  an  assessment  of  HRD  training 
requirements  can  be  made.  Trade-off  studies  on  different  system 
designs  can  assist  in  making  decisions  regarding  the  acquisition  of 
systems  requiring  the  development  of  new  training  plans,  equipment, 
and  additional  training  facilities.  Projections  can  also  be  made  of 
system  trained  personnel  and  training  support  requirements. 

The  problem  with  using  the  ISD  model  for  training  development 
is  that  the  ISD  processes  do  not  reach  maximum  levels  of  activity 
until  well  into  the  full-scale  development  phase,  when  operational  and 
maintenance  tasks  can  be  fully  defined.  This  delay  can  result  in  the 
need  to  restructure  training  courses  which  may  in  turn  delay  providing 
the  trained  operator  and  maintenance  personnel. 

A  discussion  of  early  training  estimation  procedures  within 
military  system  development  is  provided  by  Jorgensen  (1979).  Early 
training  estimations  must  consider  mission  requirements  based  on 
perceived  enemy  threat,  hardware  configurations  designed  to  counter 
threats,  and  human  resource  requirements  for  operation  and  main¬ 
tenance.  The  approach  must  flow  from  the  need  to  meet  the  performance 
objectives  of  the  stem  generated  by  threat  and  mission.  Figure  3-3 
(Jorgensen,  1979 r°  shows  the  areas  of  early  system  development 
effecting  training  estimation.  Jorgensen  reviews  important  research 
pertaining  to  the  methodological  development  of  early  training 
estimation  procedures. 

One  of  the  research  areas  examined  relevant  to  HRD 
considerations  is  task  specification.  The  Systems  Analysis  of 
Training  (SAT)  is  one  of  the  few  efforts  to  develop  a  logical 
framework  to  systematically  generate  a  training  program  foipqa  weapon 
system  in  the  early  stages  of  development  (Jorgensen,  1979).  Figure 
3-4  shows  an  example  of  the  behavioral  objective  format  taken  from  SAT 
reports.  The  SAT  approach  was  used  by  the  Air  Force  to  group  task 
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OBJECTIVE:  Title  of  Objective 

INITIAL  CONDITIONS:  State  of  the  Air  Vehicle  (e.g..  Climbing  at  2000  ft. /min.,  Electrical  Power 

Available,  Etc.) 


FIGURE  3-4.  BEHAVIORAL  OBJECTIVE  FORMAT  TAKEN  FROM  SAT  REPORTS. 


elements  into  processing  blocks  on  the  basis  of  common  behavioral 
objectives.  Task  element  data  is  categorized  in  groups  according  to 
required  skills  or  knowledges.  Skills  and  knowledges  are  then  grouped 
into  behavioral  objectives  on  the  basis  of  categorical  commonalities 
to  identify  training  requirements. 

Research  studies  which  examine  the  effectiveness  of  alter¬ 
native  training  techniques  are  helpful  in  identifying  training  methods 
which  use  HRD  considerations  to  bring  about,  more  efficient  and 
effective  training  programs.  Leibowitz  (1967ru  describes  perceptual 
research  relating  to  image  interpretation  and  discusses  implications 
for  interpreter  training.  Several  possible  ways  an  expert  image 
interpreter  learns  to  separate  relevant  cues  when  viewing  a  complex 
photograph  include: 

•  increase  in  specificity 

§  discovery  of  distinctive  features. 

Leibowitz  believes  verbal  learning  of  visual  discriminations  is 
unnatural,  and  suggests  that  a  better  method  of  learning  would  be  to 
require  the  interpreter  to  make  visual  discriminations  in  a  way  that 
uses  all  possible  combinations  of  distinctive  features. 

Bialek  (1973)31  conducted  research  to  provide  information  to 
improve  Army  training  programs.  This  project  examined  optimal 
training  strategies  for  men  of  differing  aptitudes.  A  series  of 
laboratory  studies  were  performed  which  systematically  manipulated 
learning  variables  using  different  training  methods  for  tasks  ranging 
from  simple  motor  skills  to  the  use  of  abstract  concepts  and 
principles.  Subjects  differed  in  aptitude  as  measured  by  the  Armed 
Forces  Qualification  Test.  It  was  determined  that  the  use  of 
different  training  techniques  would  be  beneficial  in  terms  of  cost. 
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time,  and  morale  for  groups  varying  in  aptitude.  Lower  aptitude 
trainees  learn  better  when  trained  with  instructional  techniques  which 
maximize  personnel  interaction.  Printed  programs  or  text  were  least 
effective  with  low  aptitude  trainees.  High  aptitude  trainees  were 
capable  of  learning  many  tasks  by  themselves  or  with  little 
supervision.  Training  programs  for  high  aptitude  trainees  should 
provide  necessary  latitude  and  autonomy  such  as  is  provided  in  self- 
paced  learning.  Further  research  is  needed  to  identify  effective 
training  techniques  if  the  capabilities  of  low  aptitude  personnel  are 
to  be  maximized. 

In  order  to  design  systems  which  make  optimal  use  of 
available  manpower,  the  human  engineer  should  be  aware  of  the  type  or 
skill  level  of  personnel  available  to  man  the  system.  Considering  the 
present  educational  and  technical  capabilities  of  armed  forces 
personnel ,  human  engineers  and  training  developers  should  work 
together  to  design  systems  within  the  capability  levels  of  available 
manpower. 

3.6  HUMAN  FACTORS  TEST  AND  EVALUATION 

A  properly  designed  human  factors  test  and  evaluation  plan 
can  be  useful  in  improving  the  quality  of  design  decisions,  correcting 
design  deficiencies  early,  and  integrating  hardware  with  the  personnel 
who  operate,  control  and  maintain  the  system. 

The  purpose  of  the  testing  is  to  determine  how  the  system 
will  perform  in  the  '•eal  world.  The  objectives  characteristic  of  a 
personnel -oriented  test  and  evaluation  program  are: 

•  Evaluate  whether  the  system  can  be  operated 
maintained  and  controlled  by  personnel 

•  Improve  machine  compatability 

•  Develop  valid  qualitative  and  quantitative  personnel 
requirements,  selection  procedures,  manning 
documents,  and  organizational  tables 

1  Evaluate  training  programs,  equipment,  and  supporting 
materials. 

Different  test  and  evaluation  techniques  vary  greatly  in 
their  fidelity,  a  variable  that  largely  determines  the  ability  of  the 


test  conditions  to  match  ttowe  in  the  real  world.  Figure  3-5 
(Chapanis  and  Van  Cott,  1972)"^  shows  the  tradeoffs  between  fidelity 
and  flexibility  of  application  of  various  test  techniques.  An 
important  part  of  designing  a  human  factors  test  and  evaluation 
program  is  deciding  which  real-world  features  to  incorporate  in  the 
test  situation.  The  validity  of  the  test  will  be  largely  determined 
by  successfully  defining  and  including  critical  variables  in  the  test 
procedure.  It  is  necessary  to  include  all  variables  which  have  an 
important  effect  on  system  performance.  Care  should  be  taken  to  make 
use  of  equipment,  personnel,  procedures,  environmental  conditions,  and 
feedback  stimuli  which  duplicate  those  appearing  in  the  operational 
system. 

A  wide  range  of  test  and  evaluation  techniques  exist 
including: 

•  Expert  opinion — should  be  used  with  caution  because 
of  their  often  subjective  and  biased  nature 

t  Human  engineering  check! ists--useful  in  the  evalua¬ 
tion  of  early  engineering  plans,  but  with  limited 
usefulness  in  the  evaluation  of  man/machine 
interaction 

•  Mockups--constructed  to  evaluate  equipments  or 
systems  before  they  are  actually  constructed 

•  Experimental  design--used  to  describe  and  measure 
relationships  between  operator  performance  and 
machine  or  system  variables 

a  Simulation--used  to  evalute  and  demonstrate  the 
application  of  specific  procedures  and  equipment  to 
specific  operations. 

From  a  human  engineering  point  of  view  simulation  techniques 
have  many  advantages  over  other  test  and  evaluation  procedures. 
Simulators  can  be  instrumented  to  collect  data  that  would  be  difficult 
to  obtain  from  real  systems,  can  be  easily  manipulated  and  used  to 
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study  processes  that  cannot  be  studied  in  real  systems  (i.e.,  crashes 
and  accidents),  and,  most  importantly,  simulators  can  be  used  to  study 
systems  and  processes  which  have  not  yet  been  constructed  or  put  into 
operation. 
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Rupe  (1963)  conducted  a  study  to  develop  procedures  for 
building  a  personnel  support  system  for  use  during  weapon  system 
development.  The  objectives  of  the  test  and  evaluation  program  for 
new  and  modified  systems  should  include  test  and  evaluation  of  the 
personnel  support  functions.  Various  aspects  of  human  factors  must  be 
investigated  including: 

•  Man-machine  compatibility 

•  Human  factors  engineering  design 

t  Personal  and  protective  equipment 

•  Physiological  factors 

•  Qualitative  and  quantitative  personnel  requirements 

•  Training  and  training  equipment  requirements 

•  Manning  and  organizational  requirements. 


Rupe  states  the  primary  objectives  of  the  personnel  support 
system  test  plan  as  being: 

•  Determine  whether  the  system  is  capable  of  being 
operated,  controlled,  and  maintained  by  Army 
personnel  programmed  for  the  system 

•  Determine  whether  personnel  performance  is  adequately 
supported  by  the  proposed,  planned,  or  established 
equipment  design,  technical  data,  job  environment, 
training,  organizational  control  procedures, 
personnel  selection,  manning,  etc. 

t  Identify  problem  areas  and  deficiencies  that  can 
degrade  system  effectiveness,  so  that  timely 
corrective  action  can  be  taken. 
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Various  methods  which  can  be  used  in  the  system  test  plan 
include  checklists,  evaluation  guides,  task  analyses,  laboratory 
experiments,  questionnaires,  interviews,  ratings,  and  paper-and-pencil 
tests.  Rupe  describes  the  test  and  evaluation  process  as  follows: 

"All  performances  required  of  personnel  in  the 
system  will  be  observed  and  evaluated. 
Troubleshooting  tasks  may  be  tested  whenever 
malfunctions  occur  during  the  hardware  test 
program,  or  by  introducing  malfunctions  in 
selected  critical  areas.  When  any  deviation 
or  difficulty  is  observed  or  reported,  the 
test  team  investigates  the  problem  and  takes 
corrective  action." 

"When  test  priorities  arise,  critical 
operations  are  given  first  priority  for  data 
collection  purposes.  For  the  most  part,  the 
operational  and  technical  requirements  of  the 
system,  including  the  operational  and 
maintenance  •  concepts,  are  used  as  criteria 
against  which  to  assess  the  adequacy  of  the 
personnel  support  system  processes  and 
products.  The  test  program  should  progress 
from  subsystem  testing  to  system  testing,  and, 
ultimately,  to  evaluations  of  human  perform¬ 
ance  in  the  operationally  configured  system 
during  simulated  mission  accomplishment." 

A  report  for  HEL  (1976)  serves  as  a  guide  for  obtaining  and 
analyzing  human  performance  data  in  a  materiel  development  project. 
This  report  gives  details  showing  how  tests  should  be  conducted  to 
ensure  the  effective  use  of  HFE  data  in  the  Army’s  materiel 
acquisition  cycle.  Human  factors  test  data  are  used  to  identify 
causes  of  human  error  and  are  used  to  assess  system  reliability  and 
effectiveness.  The  HFE  test  report  analyzes  human  performance  in 
terms  of  performance  times  and  error  rates  and  provides  qualitative 
descriptions  of  factors  contributing  to  error  rates  and  slow 
performance  times.  The  HFE  test  report  should  describe  factors  that 
produce  errors  and  suggest  ways  these  problems  can  be  corrected. 

The  nature  of  the  HFE  testing  will  vary  according  to  the 
stage  of  system  development--earl ier  phases  focus  on  functional 
allocation,  workspace  design,  criticality  of  equipment  components, 
etc.;  whereas  later  stages  assess  the  operator's  ability  to  perform 


his  assigned  tasks.  Testing  during  the  later  stages  of  system 
development  is  useful  to  determine  what  trade-offs  will  be  made  to 
improve  human  reliability.  At  this  time  tests  are  necessary  to 
determine  the  adequacy  of  personnel  selection  and  training.  It  is 
important  to  select  and  screen  all  test  participants  so  that  they  will 
closely  resemble  the  eventual  system  personnel.  Training  tests  should 
be  administered  to  determine  whether  refresher  training  is  necessary 
to  sufficiently  prepare  operators  to  operate  or  maintain  the  system 
properly.  With  proper  design  and  implementation,  testing  will  serve 
to  identify  the  sources  of  human  error  and  provide  solutions  for 
eliminating  these  areas  as  early  as  possible  in  the  system  development 
process. 


3.7  SYSTEM  INTEGRATION 

A  process  of  designing  systems  is  needed  which  integrates  all 
human  resource  technologies  so  that  human  components  are  effectively 
utilized  at  all  stages  of  system  development.  Manpower,  biomedical, 
maintenance,  and  training  HRD  elements  must  be  coordinated  at  the 
earliest  time  possible  in  the  system  development  process  in  the 
unification  of  the  total  system  environment  including  hardware, 
software,  and  personnel. 

Prerequisite  to  the  development  of  an  integrated  HRD 
technology  is  a  thorough  systems  analysis.  The  systems  analysis 
provides  the  necessary  information  serving  as  input  to  the  development 
of  a  methodology  which  systematically  applies  HRD  to  all  areas  of 
system  design.  As  an  effort  to-integrate  all  available  HRD  tech¬ 
nologies  Goclowski  et  al .  (1978r3  conducted  a  research  project  for 
the  Air  Force  Human  Resources  Laboratory.  This  research  examined  five 
human  resource  technologies  in  an  effort  to  produce  one  Coordinated 
Human  Resource  Technology  (CHRT)  which,  when  applied,  quantifies 
reliability,  maintainability,  manpower,  training,  and  job  guide 
documentation  requirements  for  a  weapon  system.  This  data  would  allow 
these  factors  to  influence  the  design,  maintenance,  operations,  and 
support  concepts  in  early  weapon  system  acquisition.  Table  3-5 
(Goclowski  et  al.,  1978 r°  provides  a  listing  of  five  HRD  technologies 
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TABLE  3-5 

HUMAN  RESOURCE  TECHNOLOGY  DATA 


DATA  ITEM  HRDT  MMM 

1.  Viable  Design  Alternatives  X 

2.  Other  Alternatives  X 

a.  Training  X 

b.  Manuals  X 

c.  SE  XX 

d.  Maintenance  X  X 

e.  Operations  X 


3.  Support  Goals 

a.  Reliability 

b.  MMH/FH 

c.  Availability 

d.  UDL 

e.  Spares 

4.  Unit  Cost  Goals 

5.  Design- to-Cost.  Goals 

6.  RIW  Considerations 


7.  Multi-National  Considerations  X 

8.  Annual  Flying  Hours  X 

9.  Number  of  Bases  X 

10.  Number  of  Aircraft  X 

11.  Crews  per  Aircraft  X  X 

12.  Crewmen  per  Crew  X  X 

13.  Crew  Makeup  X  X 

14.  Missions  X 

15.  Mission  Essential  Elements  X 

16.  Performance  X  X 

17.  Configuration  X  X 

18.  Construction  X  X 

19.  Expected  Operational  Life  X 

20.  Maintenance  Probabilities  X 

21  Maintenance  Times  X 

22.  Skill  Category  X 

23.  Skill  Level  X 

24.  Crew  Site  X 

25.  SE  Utilization  X 

26.  Safety  Hazards  X  X 


Legend: 

HRDT  -  Human  Resources  in  Design  Trade-Offs 
MW  -  Maintenance  Manpower  Modeling 
JGD  -  Job  Guide  Development 
ISO  -  Instructional  System  Development 
SOC  -  System  Ownership  Costing 
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TABLE  3-5  (Cont.) 

HUMAN  RESOURCE  TECHNOLOGY  DATA 


DATA  ITEM 


HRDT  MMM 


Available  Personnel 

a.  Years  of  Service 

b.  Labor  Rate 

c.  Scores 

d.  Retention  Rate 

e.  Predictions 
Task  Frequency 
Task  Criticality 
Task  Difficulty 

Degree  of  Procedural ization 

Content  of  Task  Information 

Job  Guide  Concept 

Job  Guide  Status 

Manual  Content 

Training  Concept 

Training  Status 

Course  Content 

Time  to  Train 

Quantity  to  Train 

Training  Resources 

Cost 

a.  SE  Investment 

b.  Manual  Investment 

c.  LRU  Spares  Investment 

d.  Aircrew 

e.  Fuel 

f.  Depot  Repairs 

g.  Facilities 

h.  Inventory 

i.  Technical  Record  Data 

j.  On/Off  Equipment  Maintenance 

k.  Training 

l.  Maintenance  Material 
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and  their  relative  contributions  in  various  data  areas.  The 
extensiveness  of  the  HRD  item  list  provides  an  indication  of  the 
comprehensiveness  and  deployability  of  this  methodology. 

The  five  HRO  technologies  which  are  integrated  in  the  CHRT 
Drocess  include  Maintenance  Manpower  Modeling  (KWM),  Instructional 
System  Development  (ISO),  Job  Guide  Development  (JGD),  System 
Ownership  Costing  (SOC),  and  Human  Resources  in  Design  Trade-Offs 
(HRDT).  Integral  to  the  CHRT  process  are  the  following  activities: 

•  Development  of  the  consolidated  data  base  (CDB) 

•  The  integrated  requirements  and  task  analysis 

•  Instructional  system  and  job  guide  development 

•  The  impact  analysis. 

■>7 

Goclowski  et  al .  (1978)  provides  a  summary  of  the  CHRT 

process. 

"The  CDB  is  developed  and  maintained  to  service  the 
CHRT  methodology.  The  CDB  data  is  then  used  for  an  • 
integrated  requirements  analysis  which  quantifies 
operations,  maintenance,  and  task  requirements  in 
terms  of  reliability  (R),  maintainability  (M), 
manpower,  and  scope  and  magnitude  of  the 
instructional  system  and  job  guide  development 
effort.  These  factors  together  with  associated  cost 
data  for  any  specific  design  are  then  provided  to  the 
user  through  the  impact  analysis.  CHRT  may  be 
reiterated  to  evaluate  various  design  and  support 
approaches.  A  traditional  but  integrated  task 
analysis  is  performed  during  full  scale  development. 

The  instructional  system  and  job  guide  products  are 
derived  from  this  task  analysis." 

The  use  of  integrated  HRD  technologies  such  as  the  one 
described  will  result  in  payoffs  which  manifest  themselves  in  the 
total  performance  of  the  fielded  system.  In  developing  a  system  which 
applies  manpower,  biomedical,  maintenance,  and  training  HRD  elements 


throughout  the  system  design  phases,  the  following  benefits  will 
result  (Kidd  and  Van  Cott,  1972). 

•  Improved  performance 

•  Reduced  training  costs 

•  Improved  manpower  utilization 

•  Fewer  losses  from  accidents  and  misuse 

e  Increase  economy  of  production  and  maintenance 

•  Improved  user  acceptance. 

3.8  CONCLUSIONS 

Applications  of  HRD  to  systems  design  and  development  have 
been  discussed  in  a  variety  of  system  areas.  A  majority  of  research 
studies  which  have  used  HRD  methodologies  during  system  development 
have  reached  the  following  conclusions: 

•  Human  factors  engineering  or  human  resources  data  can 
play  a  critical  role  in  the  overall  development  of 
systems. 

•  Timely  use  of  HRD  is  important  to  the  design  and 
development  of  effective  systems,  i.e.,  the  more  and 
the  sooner,  the  better. 

•  Successful  use  of  HRD  depends  a  great  deal  on 
priorities  attached  to  the  man-machine  interface  and 
to  the  availability  of  technically  competent  human 
factors  specialists. 

•  Effective  guides,  handbooks,  and  check  lists  have 
been  developed  and  tested  for  increasing  the  use  of 
HRD  in  system  design  and  development  processes. 

In  addition.  It  was  determined  that  the  application  of  an 
integrated  HRD  technology  is  an  effective  means  of  considering  all  HRD 
elements  so  that  human  components  are  efficiently  utilized  at  all 
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stages  of  system  development.  This  involves  the  building  of  HRD  data 
bases  in  all  system  areas  and  presenting  the  information  in  an 
organized  framework  which  would  render  it  useful  for  human  engineers 
and  system  designers.  A  recapitulation  of  the  HRD  methodologies  which 
have  been  discussed  is  presented  in  the  following  section. 

3.8.1  Available  Methodologies 

Table  3-6  summarizes  all  HRD  system  elements  discussed  in 
this  section  and  indicates  the  tradeoff  considerations  and  HRD 
methodologies  which  have  been  discussed  for  each  element. 

3.8.2  Technological  Deficiencies 

Among  the  HRD  methodologies  which  appear  to  be  weak  or  in 
need  of  further  refinement  for  purposes  of  system  development  are 
those  methods  in  the  biomedical  and  training  areas.  As  discussed  in  a 
previous  section,  experimental  methods  which  are  designed  to  examine 
the  effect  of  environmental  stressors  are  confronted  with  the  problem 
of  using  human  subjects.  There  is  still  a  great  deal  that  is  not 
understood  about  the  complex  relationships  among  stressors  which 
hampers  the  consideration  of  such  variables  in  system  design. 

Applying  HRD  methodologies  in  early  design  phases  is 
necessary  and  important  to  the  develoment  of  effective  systems.  A 
variety  of  methods  have  been  discussed  which  use  HRD  in  system 
trade-offs,  but  few  are  geared  to  the  early  phases  of  development  when 
system  specifications  are  lacking  or  incomplete.  Many  methods  of 
applying  HRD  to  training  development  are  not  utilized  until  well  into 
the  full-scale  development  phases  when  their  efficacy  is  reduced. 

New  training  methods  need  to  be  developed  which  are  geared  to 
the  capability  levels  of  the  personnel  available  to  man  the  system. 
Equipment  must  be  designed  such  that  early  hardware  descriptions  leads 
to  the  eventual  identification  of  tasks  and  associated  learning 
objectives.  This  requires  communication  between  the  training  analyst 
and  hardware  designer  in  a  common  language  which  both  parties  can 
understand.  Several  such  research  efforts  used  to  improve  design 
communication  include  the  development  of  a  simulation  language  called 
ECSL  (Extended  Continuous  Simulation  Language),  the  creation  of  CAPS 
(Computer  Aided  Programming  System),  and  Thoughtsticker--a  computer 
regulated  concept  interrogation  and  recording  device  which  forces  the 


TABLE  3-6.  AVAILABLE  HRD  METHODOLOGIES 


consideration  of  alternative  designs.  Jorgensen  (1979)  assesses  the 
future  research  needs  in  this  area  as  follows: 

"Thoughtsticker  is  used  primarily  in  the 
context  of  electrical  engineering--research  is 
needed  to  produce  a  military  oriented  system. 
Research  must  consider  the  relationships  between 
hardware  configurations  and  their  impact  on  task 
structure." 

In  human  factors  testing  as  in  all  forms  of  testing, 
tradeoffs  must  be  made  in  effecting  programs  which  are  cost  effective 
and  easy  to  administer  while  at  the  same  time  achieving  validity.  With 
the  use  of  improved  HRD  technologies  and  carefully  designed  test  and 
evaluation  plans,  the  "trial  and  error"  method  of  designing  and 
developing  systems  will  be  a  thing* of  the  past. 


Charles  C.  Jorgensen,  op.  cit. 


SECTION  IV 
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SUMMARY  AND  RECOMMENDATIONS 


4.1  EFFECTIVE  USE  OF  HRD  IN  SYSTEMS  DEVELOPMENT 

Because  of  enormous  complexities  Involved  In  major  system 
acquislton.  Army  managers  are  faced  with  a  wide  range  of  demands  on 
their  attention  and  resources.  Priorities  must  be  established  to 
rationally  cope  with  these  demands.  The  assignment  of  priorities  will 
significantly  influence,  if  not  characterize,  system  development. 

As  a  general  rule,  the  degree  of  success  achieved  in 
addressing  human  resources  issues  is  directly  proportional  to  the 
degree  of  management  emphasis;  and  the  longer  the  delay  in  applying 
this  emphasis,  the  greater  the  cost  to  address  the  issues.  All  three 
US  Army  system  developments  examined  In  this  study  confirm  this 
conclusion. 

SOTAS  is  an  example  of  high  management  priority  for  human 
resource  issues  from  the  very  beginning  of  the  program.  Although  the 
SOTAS  concept  implies  some  inherently  difficult  personnel  and  training 
problems,  the  early  attention  given  these  difficulties  has  allowed  the 
Army  to  overcome  their  adverse  impacts.  Further,  SOTAS  is  the  only 
major  Army  system  known  to  the  study  team  in  which  the  training 
devices  were  developed  in  true  sychronization  with  the  end  item. 

The  focal  point  for  addressing  human  resource  issues  in  SOTAS 
was  the  Deputy  Project  Manager  (DPM),  assisted  by  a  team  of  behavioral 
scientists  under  contract  to  the  PMO  and  Independent  of  the  hardware 
contractor.  That  the  prime  advocates  for  the  behavioral  point  of  view 
had  direct  access  to  key  PMO  management  personnel  appears  to  be  very 
significant. 

In  the  TOS  program,  on  the  other  hand,  human  resource  issues 
were  assigned  a  low  priority  relative  to  other  problems  considered  to 
be  more  pressing.  In  interviews  conducted  by  the  study  team  the  PMO 
staff  clearly  expressed  their  primary  concern  for  software  engineering 
problems.  They  described  human  resources  issues  as  one  of  “the 
ilities"  (such  as  maintainability  or  nuclear  hardening),  a  term 
Indicating  Issues  peripheral  to  the  central  thrust  of  system 
development. 


Over  its  long  history  the  TOS  materiel  development  team  has 
had  no  focal  point  for  the  address  of  human  resource  issues.  This  may 
explain  why  behavioral ists  have  had  such  a  small  impact  on  system 
development,  in  spite  of  the  considerable  amount  of  work  which  was 
done  on  TOS-related  projects.  Personnel  and  training  requirements  are 
still  largely  undefined  and  untested.  There  appears  to  be 
considerable  room  for  improvement  in  the  human  factors  engineering 
aspects  of  end  item  hardware  and  software. 

XM1  has  had  variable  degrees  of  emphasis  on  human  resource 
issues.  The  system  may  be  divided  into  four  major  areas:  operation, 
organizational  maintenance,  OS/GS  maintenance,  and  logistic  support. 
Management  interest  in  operation  was  intense  since  program  inception 
(Main  Battle  Tank  Task  Force  Report,  1972);  the  other  three  areas 
began  to  receive  major  management  attention  at  progressively  later 
dates:  organizational  maintenance  after  DT/OT  I  (1976),  DS/GS 

maintenance  after  DT/OT  II  (1978),  and  logistic  support  at  ASARC  III 
(1979).  Degree  of  success  in  addressing  human  resources  issues 
appears  in  corresponding  order,  with  a  high  degree  of  success  in 
operation  (e.g.  crew  size  and  end  item  HFE),  less  in  organizational 
maintenance  (e.g.  AMMH) ,  still  less  for  DS/GS  maintenance  (e.g. 
requirement  for  a  turbine  engine  repairman),  with  many  significant 
problems  outstanding  for  logistic  support  (e.g.  manning  levels). 

HFE  efforts  in  XM1  were  generally  assigned  to  the  hardware 
contractor.  Human  factors  aspects  of  the  end  item  were  of  particular 
interest  to  key  Army  executives.  Several  times  in  the  program 
improvements  in  the  tank's  HFE  resulted  from  inspections  by  general 
officers. 

In  all  three  systems  there  is  a  correlation  between  early 
application  of  behavioral  expertise  and  success  in  addressing  human 
resources  issues.  The  study  team  concludes  that  behavioral  experts 
should  be  an  integral  part  of  the  system  design  effort.  Whether  these 
experts  work  directly  for  the  system  PM,  for  a  contractor,  or  for  an 
independent  agency  does  not  appear  to  be  significant.  What  does 
appear  to  be  significant  is  the  degree  to  which  their  voices  are  heard 
by  the  PM. 

It  is  of  interest  to  note  that  none  of  the  military  personnel 
assigned  to  the  project  management  offices  or  the  requirements 
development  offices  were  trained  in  human  factors  or  other  behavioral 
areas.  Nor  does  there  appear  to  be  a  program  to  develop  officers  with 
such  technical  training,  although  training  in  other  technical  areas 


(such  as  engineering)  is  commonplace.  Military  personnel  with  a 
strong  behavioral  background  would  be  ideally  suited  to  translate 
between  military  managers  and  human  resource  researchers.  This  could 
result  in  a  better  focusing  of  behavioral  work  In  materiel 
development,  as  well  as  increased  credibility  for  human  resource 
demands. 

4.2  .  GENERATION  OF  CRITICAL  HRD  IN  SYSTEM  DEVELOPMENT 

In  system  development  It  Is  a  generally  accepted  practice  to 
conduct  subsystem  performance  tests  to  generate  data  to  aid 
hardware/software  design  and  validation,  outside  of  the  DT/OT  cycle. 
Examples  of  this  are:  SOTAS1  1975  test  of  the  feasibility  of 
closed-loop  targeting;  TOS1  software  requirements  studies;  and  XMl's 
ballistic  testing. 

The  use  of  testing  off-line  from  the  usual  DT/OT  process  is 
particularly  important,  since  DT/OT  is  oriented  toward  management 
decision  making.  The  pressure  for  the  system  to  "pass"  the  test 
inhibits  opportunities  for  experimental  learning. 

It  is,  however,  not  a  generally  accepted  practice  to  perform 
such  tests  to  obtain  data  specifically  on  the  personnel  and  training 
subsystems.  SOTAS  stands  out  as  a  major  exception.  As  early  as  1975 
PM  SOTAS  conducted  personnel  requirements  tests  that  Identified  key 
experience  requirements  for  operators.  Development  and  testing  of  the 
SOTAS  training  program  was  performed  continuously  and  in  conjunction 
with  system  configuration.  It  is  the  study  team's  opinion  that  the 
SOTAS  project  has  demonstrated  the  feasibility  of  early  analysis  and 
testing  of  personnel  requirements. 

Over  a  period  of  nearly  a  quarter  of  a  century  TOS  underwent 
many  test  processes,  including  field  usage  in  Europe  and  extense 
software  experimentation  at  the  Combined  Arms  Center.  However, 
critical  personnel  and  training  requirements  were  not  determined  by 
these  tests. 

A  review  of  the  case  studies  of  TOS  and  SOTAS  show  that  both 
programs  were  the  object  of  a  considerable  amount  of  behavioral 
research.  It  would  be  difficult  to  say  that  the  amount  of  effort 
applied  by  Honeywell  to  SOTAS  was  significantly  more  or  better  than 
that  applied  to  TOS  by  BESRL/ARI.  Yet,  the  SOTAS  effort  appears  to  be 
so  much  more  successful .  Why? 


It  appears  to  the  study  team  that  the  reason  is  that  the 
SOTAS  work  was  full  integrated  with  the  SOTAS  project,  while  the  TOS 
work  was  essentially  a  parallel  process.  The  TOS  project  personnel  do 
not  appear  to  have  been  very  much  involved  in  the  BESRL/ARI  work  nor 
very  aware  of  its  significance  to  their  project. 

4.3  TECHNOLOGICAL  GAPS  IN  HUMAN  RESOURCE  DATA 

Section  III  discussed  the  state-of-the-art  in  HRD,  with 
conclusions  on  research  required  in  specific  technologies.  This 
section  discusses  technological  gaps  from  the  systems  acquisition 
point  of  view. 

4.3.1  Training  Requirements 

•  The  development  of  training  requirements  appears  at  present 

to  be  more  of  an  art  than  a  science.  Even  the  development  of  an 
acceptable  skills  taxonomy--which  would  seem  to  be  a  very  basic 
building  block  to  any  scientific  approach  to  training  requirements— is 
apparently  beyond  the  state-of-the-art. 

SOTAS,  again,  appears  to  be  an  exceptional  system.  The  SOTAS 
training  program  was  developed  by  the  PM's  team  of  independent 
behavioral ists  from  Honeywell  Corporation  using  their  SOTAS  simulator 
in  conjunction  with  end  item  design  experiments.  The  time  and  expense 
of  such  an  effort  was  justified  by  the  complexity  of  the  system  and 
the  high  skill  requirements.  While  this  approach  was  a  brilliant 
success,  it  is  probably  too  costly  to  serve  as  a  model  for  most 
systems  developments. 

The  development  of  training  device  requirements  presented  one 
of  XMl's  biggest  difficulties.  The  three  year  delay  in  the 
development  of  TDRs  may  be  intepreted  as  resulting  from  a  divergence 
of  opinion  on  the  requirement  for  fidelity  in  the  training  devices. 
While  the  argument  was  finally  settled,  it  does  not  appear  to  have 
been  upon  the  basis  of  any  empirical  evidence. 


Cf.,e.g.,  J.M.  Levine,  D.  Schulman,  R.E.  Brahlek,  and  E.  Fleishman, 
Trainability  of  Abilities,  Tech.  Rep.  80-3.  Advanced  Research 
Resources  Organization,  Washington,  D.C.:  April  1980. 


It  is  the  opinion  of  the  study  team  that  there  is  a  serious 
lack  of  empirical  evidence  and  validated  scientific  theory  to  support 
rational,  convincing  decisions  on  training  requirements.  This  is 
particularly  the  case  for  determining  fidelity  requirements  for 
training  simulators.  The  need  to  determine  simulator  fidelity 
requirements  is  especially  critical,  since  technology  and  the  cost  of 
such  devices  appears  to  be  increasing  faster  than  the  experience  base. 

4.3.2  Personnel  Skill  Requirements 


Closely  related  to  determining  training  requirements  is 
determining  personnel  skill  requirements.  There  are  two  aspects  to 
this  problem: 


Designing  equipment  to  meet 
restraints 


personnel  skill 


Selecting  personnel  to  meet  skill  requirements  of 
given  equipment. 


SOTAS,  TOS,  and  XM1  all  experienced  disappointments  in  the 
first  area.  Hopes  to  use  relatively  junior  enlisted  personnel  as 
SOTAS  operators  gave  way  during  personnel  testing  early  in  the 
program.  TOS  personnel  performance  problems  during  FM  222  are  still 
not  complete  solved.  The  XM1  DT  II  revealed  potential  skill  problems 
in  organizational  maintenance  positions. 

If  the  design  cannot  be  made  to  fit  the  personnel,  then  the 
personnel  must  be  selected  to  fit  the  design.  The  steady  increase  in 
equipment  sophistication,  combined  with  the  Army's  increasing 
difficulty  in  meeting  enlistment  quotas  only  accentuates  an  already 
formidable  problem. 

The  tools  to  predict  the  success  of  personnel  at  specific 
tasks  based  on  aptitude  testing  are  still  in  a  rudimentary  state,  but 
a  number  of  efforts  have  been  made.  For  example,  during  the  M60A1E3 
OT  II  ARI/Fort  Knox  collected  data  to  determine  if  gunnery  performance 
could  be  predicted  by  psychomotor  tests;  unforturately,  small  sample 
size  limited  statistically  significant  results.  The  study  team 
believes  that  additional  efforts  to  relate  aptitude  testing  to  task 
performance  could  result  in  significanatly  improved  usage  of  scarce 
personnel  resources. 


4.3.3  Measuring  the  Impact  of  Human  Resources  on  Battle  Outcome 


As  part  of  the  decision-making  process  the  Life  Cycle  System 
Management  Model  (LCSMM)  requires  an  analysis  of  system  operational 
effectiveness  at  several  points  in  the  development  cycle.  A  Cost  and 
Operational  Effectiveness  Analysis  < COEA)  is  usually  conducted  to  meet 
this  requirement  for  major  milestones.  Other  operational 
effectiveness  analyses  may  be  conducted  to  support  the  development 
effort. 


Such  analyses  generally  measure  the  impact  of  the  system  on 
battle  outcome  in  comparison  to  a  baseline  system.  Typical  measures 
of  effectiveness  are  attrition,  survivability,  change  in  force  ratio, 
FEBA  movement,  and  battle  duration.  The  Army  has  developed  numerous 
models  and  simulations  to  support  these  analyses. 

The  degree  to  which  these  models  and  simulations  incorporate 
human  resources  aspects  of  systems  varies  according  to  level  and 
resolution.  Some  of  the  high  resolution,  small  unit  level  simulations 
(e.g.  CARMONETTE'3)  explicitly  model  operator  performance  (e.g.  time  to 
acquire  target,  time  to  engage  target  forces  on  system  performance). 

It  does  not  to  appear,  however,  that  human  performance  was 
ever  played  as  a  variable  in  the  analysis  of  XM1,  TOS,  or  SOTAS  (or  in 
any  system  known  to  the  study  team).  That  is,  some  level  of  human 
performance  was  assumed  (usually  a  level  at  or  near  the  limit  of 
system  capability)  and  fixed  among  all  comparisons. 

The  number  of  human  resources  issues  that  can  be  explicitly 
represented  in  combat  models  is  relatively  small  compared  to  the  total 
range  of  human  resources  issues.  In  particular,  no  models  appear  to 


*  USAOTEA,  M60AIE3  Operational  Test  II  (U),  0T-014-TEF.  Falls 
Church,  VAi  April  1975  (CONFIDENTIAL),  pp.  80-107. 

3 

CARMONETTE  was  the  primary  combat  model  employed  in  the  XM1  COEA  by 
the  US  Army  Concepts  Analysis  Agency  and  XM1  COEA  Update  by  the  US 
Army  Armor  Center. 


be  available  which  were  specifically  designed  to  address  the  role  of 
human  resources  issues  as  a  constitutent  part  of  the  combat  equation. 

4.4  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

To  reiterate  the  initial  point  of  the  section,  the  key  to 
successful  addressal  of  human  resources  issues  is  to  focus  management 
attention  of  the  problems  of  human  resources  as  forcefully  and  as 
early  as  possible.  In  order  to  do  this  effectively  and  consistently, 
management  must  be  shown  the  direct  relevance  of  human  resources 
requirements  on  system  effectiveness  in  a  quantitative  and  credible 
fashion.  The  two  recoimendations  presented  below  constitute  a  program 
to  establish  a  quantitative  link  between  human  resources  and  battle 
outcome. 

4.4.1  Human  Resources  Data  Base 

At  the  end  of  World  War  II  the  Army  concluded  that  there  were 
many  aspects  of  firepower  that  were  not  understood  sufficiently.  To 
remedy  this  situation  an  extensive  program  of  ballistic  testing  was 
undertaken  by  AMSAA  and  the  Ballistics  Research  Laboratory  to 
establish  a  data  base.  This  data  base  serves  as  the  empirical 
underpinning  for  efforts  to  model  the  Impact  of  firepower  on  combat 
outcome. 

A  similar  program  of  research  should  be  undertaken  to  develop 
a  data  base  relating  human  aptitudes  and  basic  skills  to  task 
performance,  training  requirements,  and  personnel  requirements.  The 
establishment  of  such  an  empirical  basis  would  significantly  advance 
the  state-of-the-art  in  personnel  and  training  subsystem  design  and 
also  enhance  the  credibility  of  the  human  resources  community  in  the 
systems  acquisition  process. 

The  development  of  such  a  data  base  will  take  many  years.  As 
the  process  unfolds  a  series  of  handbooks  should  be  written  (and 


Under  contract  to  ARI  (Contract  No.  MDA903-78-C-2030)  SA1  has 
developed  a  concept  for  a  division-level  battle  simulation  which 
specifically  models  human  performance  of  the  division  staff.  To 
the  study  team's  knowledge  this  is  the  only  detailed  design  of  a 
battle  simulation  intended  explicitly  for  the  examination  of  human 
resource  issues.  See  R.V.  Tiede,  R.A.  Burt,  and  T.T.  Bean,  Design 
of  an  Integrated  Division-Level  Battle  Simulation  for  Research, 
development,  and  Training,  VOL  1,  ARl  Technical  Report  TR4ZD,  March 


frequently  updated)  summarizing  the  available  data.  Four  specific 
areas  should  be  emphasized: 

•  Design-to-capabilities 

•  Personnel  requirements 

•  Training  device  fidelity 

•  Training  requirements. 

Additional  areas  should  be  added  as  appropriate. 

"Design-to-capabilities"  handbooks  would  be  addressed  to  the 
hardware  developer  to  assist  him  In  producing  an  end  item  which  can  be 
operated  and  maintained  by  the  type  of  personnel  who  will  actually  be 
available  to  man  the  system.  They  would  also  be  useful  in  helping  to 
identify  impossible  requirements  early  in  the  development  cycle.  Such 
handbooks  would  supplement  traditional  human  factors  engineering 
guides  by  considering  a  broader  range  of  questions  than  HFE  guides 
generally  do. 

Personnel  requirements  handbooks  would  address  a  problem 
complementary  to  that  addressed  by  "design-to-capabilities'  handbooks: 
given  tasks  and  hardware,  how  can  personnel  be ‘Selected  to  man  the 
equipment.  While  It  Is  always  more  desirable  to  handle  personnel 
requirements  through  the  "design-to-capabilities"  approach,  it  is 
advisable  to  be  well  prepared  for  cases  where  that  is  not  possible. 

Recent  and  projected  advances  In  training  device  technology 
and  corresponding  Increases  In  cost  have  made  training  device 
cost-effectiveness  an  Increasingly  important  factor  in  system 
development.  While  it  seems  clear  that  high  fidelity  devices  can 
provide  effective  training,  it  Is  not  clear  in  what  cases  lower 
fidelity,  lower  cost  devices  are  equally  effective.  Since  critical 
decisions  on  fidelity  must  be  made  In  the  concept  design  stage,  it  is 
Important  to  have  as  broad  a  data  base  as  possible  to  make  rational, 
defensible  decisions. 

Training  developers  are  under  increasing  pressure  to  cut 
training  resources  to  decrease  costs.  A  quantitative  estimate  of  the 
Impact  of  resource  cuts  would  Increase  the  trainer's  ability  to  argue 
his  position. 


4.4.2  Modeling  the  Impact  of  Human  Performance  on  Battle  Outcome 


A  program  of  research  should  be  initiated  to  establish  the 
capability  to  model  the  impact  of  human  performance  on  battle  outcome. 
Such  capability  would  allow  rational  trade-offs  between  human 
resources  and  hardware.  Several  steps  need  to  be  undertaken. 

First,  a  survey  of  currently  available  combat  models  needs  to 
be  conducted  to  determine  what  human  performance  parameters  are 
incorporated  in  what  models.  This  would  constitute  a  summary  of  the 
state-of-the-art.  It  would  also  provide  the  human  resources  community 
with  the  information  they  require  to  provide  input  to  models,  thus 
increasing  their  impact  on  system  development. 

Concurrent  with  the  first  step,  a  list  of  human  performance 
parameters  which  ought  to  be  incorporated  into  combat  models  should  be 
defined  and  developed.  Where  data  sources  for  the  parameter  values 
are  available,  they  should  be  identified.  Where  data  sources  are  not 
available,  programs  for  developing  sources  should  be  identified  (This 
clearly  relates  to  paragraph  4.4.1).  A  comparison  of  the  model  survey 
with  the  list  of  human  performance  parameters  will  show  the  scope  of 
the  problem.  It  is  virtually  certain  that  many  gaps  will  be 
identified.  These  gaps  need  to  be  prioritized  and  a  remedial  program 
initiated. 

4.4.3  Summary  of  Recommendations 

The  two  recommendations  presented  are  clearly  closely 
related.  Taken  together  they  represent  a  program  to  quantify  the 
impact  of  human  resources  on  battle  outcome.  The  first  recommendation 
calls  for  an  empirical  data  base;  the  second  applies  that  base  to 
theoretical  models. 

While  the  two  recommendations  can  be  and  are  best  executed 
together,  either  one  alone  provides  important  benefits.  The  existence 
of  a  data  base  will  assist  training  and  personnel  developers  make 
better  informed  and  more  consistent  decisions.  The  existence  of  a 
modeling  capability,  even  without  an  empirical  data  base,  will  allow 
parametric  analyses  which  can  define  the  scope  of  human  resources 
impacts. 
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APPENDIX  B 

ARMY  MAJOR  SYSTEM  ACQUISITION 


This  section  presents  an  overview  of  the  research, 
development,  and  acquisition  process  by  which  the  Army  brings  new 
major  systems  into  the  inventory.  System  acquisition  is  governed  by  a 
large  and  complex  series  of  guidelines  and  directives  issued  by 
various  interested  organizations,  from  the  Executive  Office  of  the 
President  down  to  major  Army  commands.  These  guidelines  are  intended 
to  be  both  comprehensive  and  flexible;  consequently  they  contain  a 
wide  variety  of  options  and  alternatives. 

The  overview  presented  here  is  a  "snapshot"  of  the 
acquisition  cycle  as  it  is  presently  defined.  Conflicts  between 
regulations  have  generally  been  resolved  on  a  most- recent-date  basis. 
Only  a  discussion  of  major  systems  is  considered  herein. 

B.l  OFFICE  OF  MANAGEMENT  AND  BUDGET  GUIDANCE 

The  Executive  Office  of  the  President  exercises  primary 
control  over  the  acquisition  cycle  through  the  Office  of  Management 
and  Budget  (0MB).  Policy  guidelines  have  been  promulgated  by  .the 
Office  of  Federal  Procurement  Policy  (OFPP)  in  0MB  Circular  A-109. 

A-109  policy  applies  to  all  major  federal  acquisitions  from 
hospitals  and  energy  demonstrations  to  defense  and  space  programs. 
Figure,  B-l^  shows  the  A-109  acquisition  cycle.  Four  key  decision 
points'3  are  shown  in  the  figure. 


Major  Systems  Acquisition,  0MB  Circular  A-109.  0MB,  Washington, 
D.C.:  April  5,  1976.  (See  also:  Major  Systems  Acquisition:  A 
Discussion  of  the  Application  of  0MB  Circular  No.  A-109,  OFPP 
Pamphlet  No.  1.  OFPP,  Washington,  D.C:  August  1976) 

2 

Source:  OPFF  Pamphlet  No.  1,  op.  cit. ,  p.  21. 
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A-109  decision  points  1,  2,  3  and  A  correspond  to  the  Army's 
Milestone  0,  Milestone  I  (ASARC/DSARC  I),  Milestone  II  (ASARC/DSARC 
II),  and  Milestone  III  (ASARC/DSARC  III),  respectively. 


At  the  first  key  decision  point  the  proponent  agency  must 
establish  its  requirement  for  the  new  acquisitionin  terms  of  its 
mission.  This  is  accomplished  through  the  Mission  Need  statements. 

This  is  followed  by  an  exploration  of  alternative  systems  to 
meet  the  mission  need.  The  second  key  decision  point  selects  one  or 
more  of  these  alternatives. 

The  philosophy  of  A- 109  calls  for  two  or  more  parallel, 
short-term  contracts  followed  by  competitive  tests.  The  third 
decision  point  selects  a  single  contractor  to  proceed  with  Full  Scale 
Engineering  Development  (FSED). 

After  extensive  test  and  evaluation  under  operational 
conditions,  a  production  decision  is  made.  This  is  the  fourth  key 
decision  point. 

The  A-109  process  is  primarily  concerned  with  validating  the 
need  for  and  controlling  the  expenditure  of  funds;  hence,  personnel 
and  training  considerations  are  not  explicitly  defined  therein. 
However,  personnel  and  training  considerations  are  (or  should  be) 
implicit  in  the  analysis  of  alternative  systems,  the  selection  from 
competitive  demonstrations,  and  the  pre-production  test  and 
eval uations. 

Implementation  of  the  A-109  philosophy  has  been  slow  and 
difficult  throughout  the  government.  The  Department  of  Defense  (DoD), 
which  has  taken  the  lead,  has  encountered  many  problems  and  new  DoD 
directives  are  currently  being  developed  to  clarify  the  situation. 

B.2  DEPARTMENT  OF  DEFENSE  REGULATIONS 

DoD  policy  and  0MB  Circular  A-109  are  implemented  through  a 
long  list  of  DoD  Directives  (DoDDs)  and  Instructions  (DoDIs).  The  key 
directives  for  the  acquisition  cycle  are  currently  DoDD  5000.1,  DoDD 
5000.2,  and  DoDD  5000.30.  However,  these  three  directives  are 


This  corresponds  to  the  Army's  Mission  Element  Need  Statement 
(MENS),  which  should  not  be  confused  with  the  Materiel  Need  (MN). 
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DoDO  5000.1,  Major  System  Acquisition.  January  18,  1977. 

®  DoDD  5000.2,  Major  System  Acquisition  Process.  January  18,  1977. 
^  DoDD  5000.30,  Defense  Acquisition  Executive.  August  20,  1976. 
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expected  to  be  soon  superseded  by  a  new  DoDD  5000.1  and  DoDI  5000.2, 
so  the  discussion  herein  will  address  the  new  documents. 

The  Office  of  the  Secretary  of  Defense  (OSD)  is  primarily 
concerned  with  four  major  decision  points:  approval  of  the  Mission 
Element  Need  Statement  (MENS)  and  the  Defense  System  Acquisition 
Review  Councils  (DSARCs)  I,  II,  and  III.  Consequently,  DoDD  5000.1 
and  DoDI  5000.2  are  primarily  directed  at  preparing  for,  executing, 
and  following  up  actions  taken  at  these  decision  points. 

The  key  document  at  Milestone  0  is  the  MENS.  This  document 
is  limited  to  five  pages  and  must  consider  the  mission,  threat,  need, 
constraints,  and  schedule.  Manpower  considerations  are  the  only  part 
of  the  constraints  related  to  personnel  and  training  issues. 

The  key  documents  for  entry  into  the  three  DSARCs  are  the 
Decision  Coordinating  Papers  (DCPs)  and  the  Integrated  Program 
Summaries  (IPSs).  The  DCP  is  concerned  primarily  with  funding  and 
schedule.  The  IPS,  however,  specifically  directs  the  services  to 
consider  manpower  and  training  alternatives  as  well  as  provide  an 
overview  of  the  test  and  evaluation  plan. 

The  IPS  is  a  new  requirement  and  it  remains  to  be  seen  what, 
if  any,  impact  it  has  on  human  dimension  aspects  of  systems  develop¬ 
ment.  It  does  require  consideration  of  the  impact  of  alternatives  on 
manpower  and  training,  including  job- task  identification,  requirements 
for  training  aids  and  devices,  and  plans  for  testing  and  evaluating 
manpower  and  training  requirements.  The  manpower  and  training 
sections  of  the  IPS  are  each  limited  to  two  pages. 

Recent  concern  over  the  long  term  manpower  outlook  has  caused 
the  Assistant  Secretary  of  Defense  (Manpower,  Reserve  Affairs  & 
Logistics)  (ASD(MRA&L) )  to  require  a  formal.  .Manpower  Analysis  Paper 
(MAP)  to  support  each  major  milestone/  ’  The  MAP  presents  an 


DoDD  5000.1,  Major  System  Acquisition  (Formal  Coordination  Draft). 
October  17,  1979. 
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DoDI  5000.2,  Major  System  Acquisition  Procedures  (Formal 
Coordination  Draft).  October  17,  1979. 

ASD(MRASL)  Memorandum,  Subject:  Manpower  Analysis  Requirements  for 
System  Acquisition.  August  17,  1978. 

^  For  an  example,  see:  Manpower  Analysis  Paper  (MAP)  III  AN/TTC-39 
Circuit  Switch  and  AN/TYC-39  Message  Switch.  U.S.  Army  Signal 
Center  and  Fort  Gordon:  December  4,  1979. 


analysis  of  the  manpower  requirements  by  Military  Occupational 
Specialty  (MOS)  and  skill  level  for  each  unit  type.  It  specifies 
trade-offs  among  manpower,  design,  and  logistics  elements. 


B.3  DEPARTMENT  OF  THE  ARMY  REGULATIONS 

The  Department  of  the  Army DA)  implements  DoD  guidance 
through  Army  Regulation  { AR)  lOOQ-l1^  and  supporting  ARs  and  DA 
pamphlets  and  circulars.  Additional  guidance  is  provided  by 
supplementary  regulations,  pamphlets,  and  circulars  issued  by 
subordinate  commands. 

This  paragraph  presents  a  three  part  overview  of  the  imple¬ 
mentation  of  AR  1000-1.  The  first  part  discusses  the  roles  of  the  key 
participating  commands.  The  second  considers  the  role  of  test  and 
evaluation  (T&E).  The  last  traces  the  Army  Life  Cycle  System 
Management  Model  (LCSMM). 

B.3.1  Major  Responsibilities 

The  Army  has  divided  the  responsibilities  of  the  system 
acquisition  cycle  into  four  major  areas:  The  proponent  (or  user's 
representative),  the  materiel  developer,  the  operational  tester,  and 
the  logistician.  Guidance,  coordination,  and  OSD  interface  is 
provided  by  the  DA  staff. 

B.3. 1.1  Proponent 

The  system  proponent,  or  user's  representative,  is  the  US 
Army  Training  and  Doctrine  Conmand  (TRADOC).  TRADOC's  responsi¬ 
bilities  are  divided  between  Combat  Developments  and  Training 
Developments.  Each  system  is  assigned  to  a  school  or  center.1 

For  each  major  system,  a  TRADOC  System  Manager  (TSM)  is 
chartered  by  the  Conmanding  General,  TRADOC,  to  be  the  focal  point  for 
all  TRADOC  activities  and  the  point  of  contact  for  other  commands.  He 
tasks  TRADOC  organizations  and  ensures  compliance  with  TRADOC 
requirements. 


AR  1000-1,  Basic  Policies  for  Systems  Acquisition.  April  1,  1978. 

TOS  Is  assigned  to  the  Combined  Arms  Center.  SOTAS  is  assigned  to 
Intelligence  Center.  XM1  is  assigned  to  the  Armor  Center. 


As  combat  developer,  TRADOC  establishes  the  need  and  sets  the 
requirements  for  new  systems.  It  also  establishes  manpower  and 
personnel  requirements. 

As  training  developer,  TRADOC  designs  and  executes  training 
programs.  It  must  also  review  and  approve  training  materiel s  procured 
by  the  materiel  developer.  TRADOC  establishes  requirements  for 
training  devices  and  is  responsible  for  certifying  that  players  on 
operational  tests  are  adequately  trained. 

B.3.1.2  Materiel  Developer 

The  Materiel  Development  and  Readiness  Command  (DARCOM)  is 
the  Army's  materiel  developer.  For  each  major  system  a  Project  Manager 
(PM),  chartered  by.ihe  Secretary  of  the  Army  and  assigned  to  a 
commodity  command,  1  acts  as  DARCOM *s  principal  agent.  The  PM  is 
responsible  for  developing  a  total  program  acquisition  strategy.  His 
primary  concern  is  the  development  of  hardware,  on  time  and  within 
funding  constraints.  Other  major  responsibilities  include  the 
following: 

•  Logistic  support  planning 

•  Preparation  of  baseline  cost  estimates  in  accordance 
with  work  breakdown  structure 

•  Preparation  of  outline  development  plan,  development 
plan,  resident  training  plan,  and  new  equipment 
training  plan 

•  Development  of  independent  parametric  cost  estimates 

t  Producibil ity  engineering  and  planning 

•  Identification  of  long  lead  time  component 
requirements 

t  Initial  Qualitative  and  Quantitative  Personnel 
Requirements  Information  (QQPRI)  and  MOS  decisions 


TOS  AND  SOTAS  are  assigned  to  the  Communications-Electronics 
Command  (CECOM).  XM1  is  assigned  to  the  Tank-Automotive  Command 


•  Contract  award  for  low  rate  initial  production  and 
initial  production  facilities 

•  Development  of  technical  manuals 

•  Coordination  with  test  agencies. 

As  the  focal  point  for  scheduling  and  funding,  the  PM  is,  in  practice, 
the  single  most  powerful  voice  in  the  system  acquisition  cycle. 

Because  of  the  increasing  complexity  and  cost  of  training 
devices,  DARCOM  established  the  PM  for  Training  Devices  (PM  TRADE)  for 
both  system  and  non-system  training  devices.  PM  TRADE  is  chartered  by 
the  Secretary  of  the  Army  and  reports  directly  to  DARCOM.  Originally, 
PM  TRADE  was  available  to  any  PM  who  requested  assistance.  More 
recently,  DARCOM  has  required  that  every  PM  consult  with  PM  TRADE. 

PM  TRADE  is  funded  by  the  system  PM  and  there  is  generally 
close  coordination  between  the  two  PM  offices.  In  other  respects,  PM 
TRADE'S  responsibilities  for  training  devices  exactly  parallel  that  of 
the  system  PM  for  materiel.  PM  TRADE  responds  to  the  proponent's 
requirements  (through  the  TSM).  He  is  responsible  for  developing  a 
training  device  acquisition  strategy  within  the  context  of  the  system 
acquisition  strategy. 

B.3.1.3  Operational  Tester 

The  Army's  independent  agent  for  operational  test  and 
evaluation  is  the  US  Army  Operational  Test  and  Evaluation  Agency 
(OTEA),  an  agency  of  the  Office  of  the  Chief  of  Staff,  Army,  generally 
working  directly  with  the  Vice  Chief  of  Staff,  Army. 

OTEA  is  responsible  for  planning,  managing,  and  independently 
evaluating  all  operational  tests  (OTs)  for  all  major  systems.  OTEA 
will  generally  assign  the  conduct  of  an  OT  to  a  TRADOC  test  agency 
with  players  from  a  field  unit. 

B.3.1.4  Logistician 

The  Logistician  for  the  Army  acquisition  cycle  is  the  US  Army 
Logistics  Evaluation  Agency  (LEA),  an  agency  of  the  DA  Deputy  Chief  of 
Staff  for  Logistics  (DCSLOG).  LEA's  activities  are,  however,  confined 
almost  entirely  to  review.  Logistics  requirements  are  generally  set 
by  TRADOC  and  logistics  planning  is  primarily  the  responsibility  of 
the  PM. 


*  .*■ 
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B.3.1.5  Department  of  the  Army  Staff 

The  Army  staff  provides  overall  program  coordination  and 
integration  of  the  materiel  system  into  Army.  The  focal  point  for  DA 
activities  for  a  system  is  the  DA  System  Coordinator  (DASC)  in  the 
Office  of  the  Deputy  Chief  of  Staff  for  Research,  Development,  and 
Acquisition  (DCSRDA). 

The  Deputy  Chief  of  Staff  for  Operations  and  Plans  (DCSOPS) 

is  responsible  for  establishing  and  validating  capability  goals, 

materiel  objectives  and  requirements,  overall  force  structure  design, 
basis  of  issue  plans,  and  user  testing.  DCSOPS  establishes  priorities 
for  materiel  requirements,  development,  affordability  determinations, 
and  procurement  of  equipment.  DCSOPS  designates  programs  as  major 
programs  and  has  primary  responsibility  for  supervising  Special  Task 
Forces  (STFs). 

Staff  responsibility  for  reviewing  logistic  support  belongs 
to  DCSL06.  DCSLOG  is  especially  concerned  with  integrating  system 

logistic  support  into  the  total  Army  system. 

The  Office  of  the  Deputy  Chief  of  Staff  for  Personnel 
(DCSPER)  and  its  agency,  the  Military  Personnel  Center  (MILPERCEN), 
have  responsibility  for  developing  a  personnel  system  to  meet  the 
needs  of  new  or  improved  doctrine,  organization,  and  materiel 
including  the  determination  of  new  or  revised  MOSs.  MILPERCEN  also 
develops  the  MILPERCEN  Initial  Recruiting  and  Training  (MIRAT)  Plan. 

The  Army  Research  Institute  for  the  Behavioral  and  Social 
Sciences  (ARI)  is  an  agency  of  DCSPER  and  is  responsible  for 
supervising  and  conducting  behavioral  sciences  research,  including 
assessment  of  quantitative  and  qualitative  manpower  resources  and 
requirements  systems  for  Individual  and  unit  training,  and  human 
factors  affecting  military  operations.  While  ARI  Is  not  specifically 
mandated  to  participate  in  any  given  activity  in  the  acquisition 
cycle,  it  frequently  provides  assistance  on  a  request  basis. 

B.3.1.6  User 

The  users  are  Army  field  organizations,  e.g.,  the  Forces 
Command  (FORSCOM)  or  US  Army,  Europe  (USAREUR).  The  user  is  not  an 
official  participant  in  the  acquisition  cycle,  but  Is  represented  by 
TRADOC.  In  practice,  however,  coordination  with  user  units  for  input 
and  force  development  testing  can  be  critical  in  systems  development. 


6.3.2  Test  and  Evaluation 
B.3.2.1  Types  of  Test  and  Evaluation 

Developmental  test  and  evaluation  (DT&E)  is  conducted  to 
assist  the  engineering  design  and  development  processes  and  to  verify 
attainment  of  technical  performance  specifications  and  objectives.  As 
such,  it  is  critical  to  determining  whether  or  not  a  system  is 
acceptable  for  military  use.  It  is  accomplished  in  factory, 
laboratory,  and  proving  ground  environments  using  experienced  and 
qualified  civilian  and  military  personnel.  To  the  maximum  extent 
possible,  contractor  and  government  development  testing  is  integrated 
into  one  test  cycle  during  the  demonstration  and  validation  phase  and 
another  during  the  full-scale  engineering  development  phase  of  the 
materiel  acquisiton  process. 

Operational  test  and  evaluation  (OT&E)  is  that  test  and 
evaluation  conducted  to  estimate  a  system's  operatonal  effectiveness 
(including  military  utility,  vulnerability,  and  survivability),  and 
operational  suitability  (including  compatibility,  rationalization, 
standardization,  interoperability,  reliability,  availability, 
maintainability,  logistic  supportabil i ty ,  safety,  health,  human 
factors,  and  trainability) ,  as  well  as  the  need  for  any  modifications. 
In  addition,  OT&E,  provides  information  on  organization,  personnel 
requirements,  doctrine,  and  tactics. 

Operational  test  and  evaluation  is  accomplished  by  units 
consisting  of  operational  and  support  personnel  for  the  type  and 
qualifications  of  those  expected  to  use  and  maintain  the  system  when 
deployed,  and  is  conducted  in  as  realistic  an  operational  environment 
as  possible.  A  realistic  operational  environment  includes  tactical 
operations  conducted  in  accordance  with  the  combat  developer's 
operational  mode  summary  which  specifies  the  number  and  type  of  combat 
operations  during  a  period  of  time.  The  environment  under  which  these 
operations  are  conducted  may  include  the  employment  of  opposing 
forces;  electronic  and  other  enemy  counter-measures;  chemical, 
biological,  and  radiological  warfare;  and  smoke  or  other  forms  of 
battlefield  obscuration.  Where  appropriate,  operations  may  be 
conducted  in  urban  training  areas.  Independent  evaluations  of 
operational  tests  are  provided  directly  to  each  member  of  the  decision 
review  body. 

Force  development  test  and  experimentation  (FDTE)  are  tests 
that  are  performed  to  support  the  force  development  processes  by 


examining  the  impact,  potential,  effectiveness,  and  interdependence  of 
selected  concepts,  tactics,  doctrine,  organization,  and  materiel. 
They  support  the  materiel  acquisition  process  by  providing  data  to 
assist  in  the  development  of  requirements,  to  develop  fundamental  data 
necessary  for  a  full  understanding  of  the  performance  of  a  materiel 
system,  or  to  assist  in  validating  doctrine  and/or  tactics  to  counter 
a  possible  threat  response  to  a  system  once  deployed.  FOTE  may  be 
used  to  develop  the  concept  of  employment,  determine  operational 
feasibility,  estimate  the  potential  operational  advantage  of  a 
proposed  system,  and  assist  the  combat  and  materiel  developers  in  the 
development  of  requirements  documents. 

B.3.2.2  An  Example  of  the  Test  Cycle 

The  six  basic  test  cycle  documents  and  the  process  they 
follow  are  shown  in  Figure  B-2.  These  same  documents  are  shown  in 
Figure  B-3  with  enough  elaboration  to  reflect  the  0T4E  process  within 
a  cycle. 

The  OT&E  cycle  starts  with  identification  of  operational 
Issues  (or  a  revision  of  them  if  there  was  a  previous  cycle)  by 
proponent  commands  or  agencies.  The  issues  form  the  basis  for 
initiating  (or  revising)  the  Independent  Evaluation  Plan  (IEP).  The 
IEP  programs  the  use  of  all  available  data,  regardless  of  source,  to 
evaluate  the  system's  operational  effectiveness  and  suitability.  When 
the  IEP  is  sufficiently  developed  to  identify  what  data  are  required 
from  operational  tests  and  operational  performance  criteria,  test 
concepts  are  prepared  (or  revised)  for  each  required  OT.  The  test 
concept  also  forms  the  basis  for  preparing  (or  revising)  an  outline 
test  plan  (OTP)  for  each  required  operational  test. 

After  the  IEP  for  a  phase  is  approved,  the  test  design  plan 
(TDP)  is  prepared.  The  TDP  delineates  only  as  much  of  the  test 
planning  as  is  necessary  for  the  approval  authority  to  be  assured  that 
the  test  will  satisfy  its  objectives,  leaving  some  flexibility  in  the 
detailed  planning  to  the  test  director.  Preparation  of  the  TDP 
requires  input  from  the  materiel  developer  concerning  maintenance  and 
new  equipment  training  (NET)  and  from  the  combat  developer  and  trainer 
concerning  means  of  employment,  organization,  logistical  concepts, 
threat,  mission  profiles,  test  environment,  and  training.  The  inputs 
are  referred  to  as  the  materiel  developer  test  support  package  (TSP) 
and  the  combat  developer  TSP.  When  the  TDP  has  been  approved  a 
detailed  test  plan  (TP)  is  prepared  and  used  by  the  test  director. 
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After  the  test  has  been  conducted,  the  test  organization 
reports  the  conditions  under  which  the  test  was  run  and  the  data 
results.  The  test  reports  are  limited  to  findings  of  fact,  including 
such  sunroary  calculations  as  are  called  for  in  the  test  design  plan, 
but  do  not  draw  inferences,  make  recommendations,  or  advance  evalua¬ 
tive  judgements.  The  designated  independent  evaluator  reports  a 
conclusion  for  each  operational  issue  of  the  test  with  due  con¬ 
sideration  to  any  relevant  criteria  which  may  exist,  along  with  an 
evaluation  of  the  adequacy  and  validity  of  the  operational  test.  The 
conclusion  as  to  operational  effectiveness  of  the  evaluated  system  or 
item  contained  in  the  Independent  Evaluation  Report  (IER)  is  based  on 
data  from  all  sources  including  OT,  OT,  FDTE,  studies,  simulations, 
and  analysis,  and  takes  into  account  the  validity  and  relevance  of 
each  datum  source.  The  operational  IER,  then,  is  supplied  as  one  of 
several  documents  directly  to  the  ASARC  for  their  consideration.  The 
decision  resulting  from  the  ASARC  is  the  basis  for  revising  the  opera¬ 
tional  issues  and  repeating  the  cycle,  unless  the  decision  is  the 
final  one  in  the  acquisition  cycle. 

B.3.3  Life  Cycle  System  Management  Model 

The  LCSMM  is  an  event-step  process  by  which  Army  materiel 
systems  are  initiated,  validated,  developed,  deployed,. ^supported, 
modified,  and  disposed.  Promulgated  in  DA  Pamphlet  11-25, 13  the  LCSMM 
summarizes  and  organizes  the  requirements  of  AR  1000-1  and  its 
supporting  regulations  and  circulars. 

Unfortunately,  the  LCSMM  has  not  been  revised  since  1975, 
making  it  considerably  out  of  date.  This  paragraph  provides  an 
overview  of  an  updated  LCSMM  from  program  initiation  until  the 
production  and  deployment  decision.  The  emphasis  is  placed  on 
personnel  and  training  related  events.  Figure  B-4  illustrates  the 
LCSMM. 

B.3.3. 1  Program  Initiation  {Milestone  0) 

As  part  of  its  mission,  TRADOC  conducts  continuing  analyses 
of  mission  areas  to  identify  requirements  for  enhanced  capabilities. 
When  a  mission  need  is  identified,  TRADOC,  in  coordination  with 


DA  Pamphlet  11-25,  Life  Cycle  System  Management  Model  for  Army 
Systems.  HQDA:  May  1975. 
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EXPLORATION  OF  ALTERNATIVE  SYSTEM  CONCEPTS 


DEMONSTRATION  AND  VALIDATION  DECISION  (MILESTONE  I) 


DEMONSTRATION  AND  VALIDATION  DECISION  (MILESTONE  I) 


FIGURE  B-4.  LIFE  CYCLE  SYSTEM  MANAGEMENT  MODEL  (PART  4  OF  11) 


DEMONSTRATION  AND  VALIDATION 


FIGURE  &-4.  LIFE  CYCLE  SYSTEM  MANAGEMENT  MODEL  (PART  5  OF  11) 


DEMONSTRATION  AND  VALIDATION 


FULL  SCALE  ENGINEERING  DEVELOPMENT 


FUL  SCALE  ENGINEERING  DEVELOPMENT  PRODUCTION  AND  DEPLOYMENT  DECISION 


DARCOM,  prepares  a  MENS.  The  MENS  will  describe  the  operational  task 
to  be  accomplished  and  will  not  be  cast  in  terms  of  capabilities  and 
characteristics  of  a  hardware  or  software  system. 

B.3.3.2  Exploration  of  Alternative  System  Concepts  Phase 

The  purpose  of  the  second  phase  is  to  explore  and  identify 
alternative  system  concepts  selected  from  all  available  sources.  This 
exploration  will  generally  be  undertaken  by  a  STF  under  DCSOPS 
direction  or  by  a  Special  Study  Group  (SSG)  chartered  by  CG,  TRADOC. 
A  Study  Advisory  Group  (SAG)  will  generally  be  used  in  conjunction 
with  an  STF  or  SSG. 

At  the  time  of  the  materiel  concept  investigation,  "person¬ 
nel"  is  addressed  only  in  very  general  terms.  The  TRADOC  proponent 
may  investigate  at  a  very  general  level  the  impact  of  the  materiel 
concept  upon  recruiting,  MOS  structure,  training,  and  manpower 
authorizations.  Questions  such  as  the  following  must  be  asked  and 
eventually  answered: 

•  Can  it  reasonably  be  assumed  that  soldiers  with  the 
required  mental  and  physical  skills  will  be  recruited 
and  made  available  to  operate  and  maintain  the 
proposed  system? 

•  Will  current  or  future  manpower  authorizations 
support  the  system? 

•  What  will  be  the  impact  on  the  current  personnel 
structure? 

•  Will  personnel  trade-offs  be  required?  What  will  be 
the  effect  on  proposed  system  objectives? 

•  What  is  the  human  resources  development  impact  of  the 
proposed  system? 

•  What  cost-effective  trade-offs  are  possible  to 
capitalize  on  the  human  resources  aspects  for  the 
system  instead  of  materiel  aspects? 

When  a  concept  has  been  formulated,  the  combat  and  training 
developers  should  begin  planning  the  training/training  device 


requirements  for  the  conceptualized  system.  These  requirements  can 
only  be  stated  in  general  terms;  however,  the  planning  must  proceed  at 
the  earliest  possible  time  since  training  requirements  can 
(theoretically)  influence  materiel  design.  The  first  element  of  the 
requirements  is  a  Task  and  Skill  Analysis  (TASA),  based  on  the  concept 
of  the  materiel.  The  TASA  should  answer  the  question,  "What  is  the 
best  allocation  of  functions  among  operations,  maintenance,  and 
materiel?"  Following  the  completion  of  the  rough  TASA,  there  should 
be  an  assessment  of  the  general  training/ training  device  requirements. 

A  general  statement  of  personnel  requirements  can  then  be 
addressed: 

•  Individual  skills  and  skill  levels  required 

•  Estimate  of  the  number  of  personnel  required  to 
operate  and  maintain  the  system 

•  Unique  physical  and  mental  considerations. 

TRADOC,  in  coordination  with  DARCOM,  prepares  a  Letter  of 
Agreement  (LOA)  for  HQDA  approval.  The  LOA  is  the  requirements 
document  which  supports  the  Demonstration  and  Validation  (DVAL)  phase. 

Concurrent  with  the  preparation  of  the  LOA,  the  rough  TASA  is 
analyzed  and  subdivided  into  three  categories:  machine  functions  (or 
those  which  the  developer  believes  could  be  best  performed  by  the 
hardware),  shared  functions  (man-machine  Interface),  and  purely  human 
tasks.  From  the  latter  two  categories,  critical  tasks  are  identified 
(as  defined  in  TRADOC  Pamphlet  350-30). 1  These  critical  tasks  are 
those  most  likely  to  require  formal  training  and  will  serve  as 
guidelines  for  developing  the  training  support  plan. 

B.3.3.3  Demonstration  and  Validation  Decision  (Milestone  I) 

With  the  approval  of  the  LOA,  formulation  of  a  system  concept 
and  an  acquisition  strategy  is  initiated.  The  Secretary  of  the  Army 
charters  a  PM  who  reports  through  a  DARCOM  commodity  command.  OTEA  is 
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TRADOC  Pamphlet  350-30.  Interservice  Procedures  for  Instructional 
Systems  Development.  Fort  Monroe,  VA:  1  August  1975. 
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named  as  the  operational  tester,  while  OCSOPS  issues  force  level 
guidance  to  the  major  commands. 

The  PM  must  identify  to  the  proponent  any  organizational 
equipment,  training,  and  personnel  trade-offs  that  would  be  required 
if  the  system  is  added  to  the  total  force  structure.  This  information 
will  be  used  by  TRADOC  to  develop,  in  coordination  with  the  PM,  the 
organizational  and  operational  concepts  which  will  be  incorporated  in 
the  Concept  Formulation  Package  (CFP)  and  also  form  the  basis  for  the 
Provisional  QQPRI  and  the  first  Basis  of  Issue  Plan  (BOIP). 

Training  support  planning  is  focused  toward  considerations 
that  will  influence  the  design  of  the  materiel  and  proposed  training 
devices.  These  considerations  may  influence  trade-offs  required  in 
later  events.  The  basic  document  for  planning  is  the  outline 

Individual  and  Collective  Training  Plan  (ICTP).  As  development 

progresses,  the  ICTP  is  updated  and  modified  as  needed.  As  more  is 

known  about  system  training  requirements,  the  trainer  develops  plans 
for  training  methods,  programs,  and  media;  training  devices;  systems 
hardware  for  training;  and  scheduling  requirements  for  training  user 
and  support  personnel . 

The  CFP  provides  for  the  evaluation  of  alternative  concepts 
and  selection  of  the  best  concepts  as  a  coordinated  combat  developer 
and  materiel  developer  effort.  The  CFP  consists  of  a  Trade-off 

Determination  (TOD),  a  Trade-Off  Analysis  (TOA),  a  Best  Technical 
Approach  (BTA) ,  and  a  preliminary  Cost  and  Training  Effectiveness 
Analysis  (CTEA)  and  Cost  and  Operational  Effectiveness  Analysis 
(COEA).  The  TOD  is  conducted  by  the  PM  and  includes  alternative 
personnel  support  concepts,  together  with  the  advantages  and 
disadvantages  of  each,  for  each  design  alternative.  Upon  completion, 
the  TOD  is  furnished  to  TRADOC.  The  TOA  of  the  concepts  identified  in 
the  TOD  is  conducted  by  TRADOC  and  is  returned  to  the  PM.  The  BTA  is 
jointly  prepared  by  TRADOC  and  the  PM  and  describes  the  optimum 
contribution  of  an  operational  support  concept  for  further  development 
and  evaluation  during  the  validation  and  full  scale  development  of  the 
item.  The  CTEA/COEA  Is  conducted  by  TRADOC  and  addresses  the 
effectiveness  of,  among  other  things,  the  personnel  support  concept  in 
terms  of  operational  availability. 

The  PM,  in  coordination  with  TRADOC,  OTEA,  and  LEA,  will 
prepare  an  Outline  Acquisition  Plan  (OAP),  which  presents  the 
acquisition  strategy  through  system  demonstration  and  validation.  The 
Organizational  and  Operational  Concept  (0&0),  the  Coordinated  Test 


Program  (CTP),  and  plans  for  technical  development,  management, 
finance,  personnel  and  training  requirements,  and  logistic  support. 

In  preparation  for  the  DSARC  decision  to  proceed  with 
demonstration  and  validation,  HQDA  prepares  the  DCP  I,  the  IPS  I,  and 
an  Independent  Parametric  Cost  Estimate  (IPCE).  The  ASARC  I 
formulates  the  Army's  position  for  the  Secretary  of  the  Army's 
approval.  The  DSARC  I  formulates  the  DoD  position  for  the  Secretary 
of  Defense's  approval. 

B.3.3.4  Demonstration  and  Validation  Phase 

Based  on  ASARC/DSARC  I  guidance,  the  OAP  is  updated  by  the  PM 
in  preparation  for  the  award  of  Advanced  Development  (AD)  contracts. 
The  philosophy  of  0MB  Circular  A- 109  calls  for  multiple  awards  to 
enhance  cost-effectiveness  through  competition. 

When  the  PM  prepares  the  Request  for  Proposal  (RFP),  TRADOC 
must  ensure  that  the  proposed  contracts  contain  the  basic  critical 
personnel  criteria  required  for  operation  and  maintenance.  This 
includes  the  outputs  from  all  previous  Investigations  and  events.  The 
primary  concern  is  development  of  hardware  that  the  average  soldier 
can  effectively  operate  and  maintain.  Constraints  based  on  previous 
personnel  planning  must  be  part  of  the  contracts. 

A  specification  of  the  Advanted  Development  contracts  must  be 
that  the  contractor(s)  furnish  as  early  as  possible  data  for  a  TASA 
for  each  proposed  operator  and  maintainer.  Their  analysis  will  be 
used  for  planning  training  requirements  (updating  ICTP),  planning  MOS 
requirements,  and  developing  test  issues  for  DT/OT  I. 

Using  the  contractor  furnished  TASA,  TRADOC,  in  concert  with 
the  PM  must  determine  critical  tasks,  evaluate  training  and  training 
device  requirements  for  the  tasks,  and  make  an  initial  estimate  of 
whether  the  operator  and  maintainer  will  require  new  MOSs  or 
modification  of  existing  MOSs. 

The  documentation  for  the  DT/OT  I  cycle  is  then  prepared. 
The  basis  for  testing  Is  the  CTP  of  the  OAP.  It  is  structured  to 
ensure  tasks  associated  with  the  hardware  are  tested  and/or  evaluated. 
These  Include  all  operational,  maintenance,  and  support  tasks  that  are 
required  to  make  the  system  effective.  Each  task  must  be  identified 
and  an  estimate  made  for  the  time  required  for  performance.  The  man- 
machine  interface  of  mental  and  physical  requirements  for  the  soldier 


expected  to  operate  and  maintain  the  system  must  be  tested  also. 
TRADOC  prepares  the  personnel  support  input  to  the  TSP  and  forwards  it 
to  the  PM  to  be  used  in  the  preparation  of  the  DT  TDP  and  to  the  test 
organization  to  be  used  in  the  preparation  of  the  OT  TDP. 

After  DT/OT  I  has  been  completed  and  the  test  reports 
prepared,  thq  proponent,  in  coordination  with  the  PM,  must  evaluate 
the  results.  The  operation  and  maintenance  task  lists  must  be 
reviewed  and  verified.  The  personnel  criteria  that  were  specified  in 
the  test  Issues  should  be  reviewed  and  revised  if  necessary.  From  the 
preceding  actions,  the  outline  training  plan  can  be  updated,  the 
Issues  for  further  test  developed,  and  the  basic  information  for  an 
updated  QQPRI  accumulated. 

The  DARCOM  NET  element  and  TRADOC  refine  training  require¬ 
ments  for  operator  and  logistic  personnel  based  on  the  outputs  of 
DT/OT  I  and  any  other  new  personnel  training  requirements  determined 
in  previous  or  ongoing  Investigations.  They  also  analyze  technical 
documentation  to  determine  personnel  and  training  impact  and  plan 
participation  in,  and  attendance  at,  the  staff  planners  course,  the 
technical  orientation  course,  and  the  instructor  and  key  personnel 
course.  The  updated  training  planning  will  be  documented  by  the 
materiel  developer  and  should  include  a  description  of  training 
devices,  training  methods  and  media,  training  extension  courses, 
soldiers  and  commanders  manuals,  skill  qualifications  tests,  ICTP 
material,  field  manuals,  and  other  requirements  necessary  to  provide 
for  Individual  and  unit  training. 

DARCOM  elements  will  revise  the  QQPRI  and  send  it  through  US 
Army  Materiel  Readiness  Support  Activity  (MRSA)  to  TRADOC.  The  TRADOC 
approved  QQPRI  input  will  be  returned  to  MRSA  for  further  action  and 
forwarding  to  MILPERCEN. 

Initial  unit  structures  are  revised  by  TRADOC  proponent 
schools/agencies  using  combat  developer  studies,  QQPRI,  and  BOIP 
feeder  data.  The  DARCOM  proponent  command  provides  feeder  data 
through  the  Equipment  Authorization  Review  Agency  to  TRADOC,  who  will 
task  the  proponent  school  to  revise  the  BOIP  to  reflect  any  changes. 

TRADOC  will  conduct  a  COEA  of  the  system.  As  part  of  this 
effort,  a  CTEA  will  be  conducted  on  the  training  subsystem. 

The  materiel  developer  is  responsible  for  the  initiation, 
development,  and  publication  of  the  New  Equipment  Training  (NET)  Plan. 


TRADOC  will  assist  by  providing  input  as  applicable  to  MOS  training 
prior  to  formal  reviaw/update  at  the  Training  and  Support  Work  Group 
(TSWG)  meetings.  TRADOC  schools  will  actively  participate  (throughout 
the  life  cycle)  in  the  DARCOM  sponsored  TSWGs.  DARCOM  will  prepare 
elements  of  the  ICTP  for  which  it  has  functional  responsibility  and 
forward  it  to  TRADOC  for  inclusion  in  the  ICTP.  The  designated  TRADOC 
proponent  develops  the  respective  individual  and  collective  training 
plans  based  upon  QQPRI,  task  analysis,  CTEA,  and  materiel  developer 
input.  In  addition  to  milestone  schedules,  the  ICTP  should  include 
training  concepts,  estimated  training  class  quotas  by  MOS  and  skill 
levels,  a  description  of  required  training  literature,  training 
extension  course  listings,  audio-visual  media,  simulators,  training 
devices,  and  hardware  requirements  for  conducting  institutional 
instruction. 

TRADOC  is  responsible  for  the  development  of  the  Required 
Operational  Capability  (ROC).  The  ROC  will  include  a  personnel 
assessment  that  will  identify  personnel  considerations  which  have  an 
impact  on  further  full-scale  development  of  the  materiel  system  and 
personnel  support.  TRADOC  will  ensure  that  the  ROC  Includes: 

•  Personnel  interface  with  existing  and  projected 
equipment 

•  Training  and  training  device  requirements 

•  Desired  system  safety  and  human  engineering 
characteristics. 


The  STF  or  SSG  may  be  reconvened  to  review  the  progress  of 
the  program  in  preparation  for  the  next  DSARC  decision. 

A  MIRAT  Plan  is  prepared  by  MILPERCEN  and  coordinated  with 
the  Recruiting  Command. 

The  PM  prepares  the  Acquisition  Plan  (AP)  in  coordination 
with  TRADOC.  The  AP  presents  the  acquisition  strategy  through  FSED. 
the  AP  should  Include  identification  of  new  skills,  individual  and 
crew  training  requirements.  Skill  Performance  Aids  (SPA),  training 
devices,  training  facilities,  and  associated  schedules. 

B.3.3.5  Full-Scale  Engineering  Development  Decision  (Milestone  II) 

In  preparation  for  ASARC/DSARC  II,  a  DCP  II,  IPS  II,  and  an 
updated  IPCE  are  prepared.  The  Secretary  of  Defense’s  approval 
initiates  the  Full-Scale  Engineering  Development  (FSED)  phase. 
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The  PM  prepares  for  future  production  by  Producibility 
Engineering  and  Planning  (PEP)  and  a  Manufacturing  Methods  and 
Technology  Program  (MTP). 

B.3.3.6  Full-Scale  Engineering  Development  Phase 

FSED  is  initiated  with  the  award  of  the  Engineering 
Development  (ED)  contract.  While  the  ED  model  is  being  developed, 
DT/OT  II  is  revised  and  refined  planning  begins.  Major  emphasis  is 
placed  on  demonstrating  during  the  DT/OT  II  phase  that  all  key 
criteria  which  have  been  established  for  the  system  can  be  satisfied, 
including  training  requirements  and  personnel  supportability.  DT  II 
must  be  carefully  planned  to  provide  an  adequate  assessment  of 
training  and  personnel  and  minimize  associated  risks.  OT  II  must 
validate  the  suitability  of  personnel  support  and  training  (to  include 
training  devices).  The  operational  tester  prepares  a  TDP  which 
identifies  the  test  objectives  for  materiel  being  tested  during  OT  II. 
Personnel  input  to  the  TDP  will  provide  for  a  comprehensive  evaluation 
of  system  supportability,  doctrine,  organizational  procedures,  and 
user  training  in  accordance  with  the  approved  personnel  support 
concept.  TRADOC  provides  test  issues,  associated  criteria,  and  the 
combat  developer/trainer  test  support  packages  to  the  test 
organization.  The  package  includes  statement  of  organization  and 
basis  of  issue,  training  plan,  and  statement  of  personnel  support 
concepts.  Action  must  be  taken  to  identify  and  stabilize  personnel 
for  the  test. 

Instructors,  schooled  by  a  selected  contractor,  will  train 
key  operator  and  support  personnel  for  the  conduct  of  OT  II  using  the 
TRADOC-approved  training  program  to  be  implemented  when  the  system  is 
approved  for  deployment.  Normally,  SPA  materiel  should  be  available 
for  their  training  also. 

Following  completion  of  DT/OT  II,  the  responsible  test 
agencies  prepare  test  reports.  These  reports  contain  the  data 
obtained  and  the  conditions  which  actually  prevailed  during  test 
execution.  The  test  reports  also  contain  an  analysis  of  the  personnel 
test  results  versus  the  personnel  test  objectives.  OTEA  prepares  an 
IER  based  upon  the  OT  report,  studies  and  other  appropriate  sources, 
to  include  the  DT  report.  When  determining  the  military  worth  of  the 
equipment  personnel  aspects  as  well  as  operational  aspects  are 
considered.  Potential  personnel  problems,  training,  organizational 
and  doctrinal  implications,  and  the  Impact  of  fielding  or  not  fielding 
the  equipment  are  some  of  the  factors  considered.  The  IER,  together 


with  test  reports  and  supporting  documentation  (comments  from  other 
agencies,  etc.),  are  provided  to  the  DSARC/ASARC  members  at  least  two 
weeks  prior  to  the  preliminary  review.  The  data  contained  in  these 
documents  should  assist  the  decision  makers  in  reaching  a  valid  and 
reasonable  decision. 

The  final  QQPRI  is  developed  by  the  materiel  developer 
approximately  thirty  months  prior  to  scheduled  deployment  of  new 
materiel  items.  Some  considerations  of  the  proponent  school /agency , 
while  coordinating  with  other  interested  school  s/agencies,  are: 

•  Are  all  system  components  and  subcomponents 
identified  and  listed  in  QQPRI  documentation,  to 
include  MOS  and  annual  maintenance  man  hours  for  each 
level  of  maintenance? 

•  Is  the  MOS  proper  to  support  equipment  in  the 
proposed  Table  of  Organization  and  Equipment  (TOE)? 

t  Are  skill  levels  correct  for  the  MOS  and  expertise 
required? 

•  Will  training  be  sufficient  to  provide  required 
experti se? 

•  Will  there  be  a  sufficient  number  of  MOS  trained 
personnel  in  the  field  to  support  the  equipment? 


Based  on  data  from  OT  II,  the  proponent  makes  any  changes  in 
the  unit  structure  for  the  new  system  and  incorporates  them  into  the 
BOIP.  Normally,  an  update  of  BOIP  incudes  planned  changes  in  other 
equipment  and  in  personnel  necessary  to  accommodate  new  items  of 
equipment. 

TRADOC  will  continue  to  update  training  planning  to  validate 
personnel  training  requirements.  The  training  plan  will  be  expanded 
and  revised  in  preparation  for  initiation  of  resident  training.  Test 
reports  of  DT  I/OT  I,  DT  II/OT  II  will  be  used  to  provide  information 
on  the  use  and  effectiveness  of  training  personnel.  If  not  previously 
provided,  proponent  schools  will  take  action  to  obtain  logistical 
support  analysis  requirements  (LSAR)  output  summary  sheets  from  the 
materiel  developer.  Draft  equipment  publications,  LSAR  summaries,  and 
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LIST  OF  ACRONYMS 


ACB 

AD 

AFSC 

AIT 

ALARM 

AMSAA 

AMMH 

AO 

AOS 

AP 

AR 

ARI 


ARTADS 

ARTOC 

ASARC 

ASD(MRAiL) 

ASI 

ASIC 

AVCSA 


Army  Classification  Battery 

Advanced  Development 

US  Air  Force  Systems  Command 

Advanced  Individual  Training 

Alerting  Long  Range  Radar  for  Moving  Targets 

US  Army  Materiel  Systems  Analysis  Agency 

Annual  Maintenance  Man-Hours 

Action  Officer 

Add-On  Stabilization 

Acquisition  Plan 

Army  Regulation 

US  Army  Research  Institute  for  the  Behavioral  and  Social 
Sciences 

Army  Tactical  Data  Systems 
Army  Tactical  Operations  Center 
Army  Systems  Acquisition  Review  Council 
Assistant  Secretary  of  Defense  (Manpower,  Reserve 
Affairs,  and  Logistics) 

Additional  Skill  Identifier 
All -Source  Intelligence  Center 
Assistant  Vice  Chief  of  Staff,  Army 


BESRL 

BDE 

BDMSC 

BOIP 

BTA 


Behavioral  Sciences  Research  Laboratory 
Brigade 

BDM  Services  Company 
Basis  of  Issue  Plan 
Best  Technical  Approach 


CAC 

CAPS 


CDB 

CDEC 

CECOM 

CFP 

CGSC 

CHRT 

COEA 


US  Arn\y  Combined  Arms  Center 
Computer-Aided  Programming  System 
Command  and  Control 

Command,  Control,  Communication,  and  Intelligence 
Consolidated  Data  Base 

US  Army  Combat  Developments  Experimentation  Command 

US  Army  Communlcatlons-Electronics  Command 

Concept  Formulation  Package 

US  Artny  Cotimand  and  General  Staff  College 

Coordinated  Human  Resource  Technology 

Cost  and  Operational  Effectiveness  Analysis 


COFT  Conduct  of  Fire  Trainer 

CP  Command  Post 

CRT  Cathode  Ray  Tube 

CSA  Chief  of  Staff,  Army 

CTEA  Cost  and  Training  Effectiveness  Analysis 

CTP  Coordinated  Test  Program 

DA  Department  of  the  Army 

DARCOM  US  Army  Materiel  Development  and  Readiness  Command 

DCC  Division  Computer  Center 

DCP  Decision  Coordinating  Paper,  or  Development  Concept 

Paper 

DCSLOG  Deputy  Chief  of  Staff  for  Logistics  (KDQA) 

DCSOPS  Deputy  Chief  of  Staff  for  Operations  and  Plans  (HQDA) 

DCSPER  Deputy  Chief  of  Staff  for  Personnel  (HQDA) 

DCSRDA  Deputy  Chief  of  Staff  for  Research,  Development  and 

Acquisition  (HQDA) 

DDR&E  Director,  Defense  Research  and  Engineering 

DEVTOS  Developmental  Tactical  Operations  System 

DIV  ARTY  Division  Artillery 

D/K/P  Display /Keyboard  and  Printer 

DoD  Department  of  Defense 

DoDD  DoD  Directive 

DoDI  DoD  Instruction 

DPM  Deputy  Project  Manager 

DS  Direct  Support 

DSARC  Defense  Systems  Acquisition  Review  Council 

DT  Developmental  Test 

DTOS  Division  Tactical  Operations  System 

DTAE  Developmental  Test  and  Evaluation 

DVAL  Demonstration  and  Validation 


ECOM  US  Army  Electronics  Command 

ECSL  Extended  Continuous  Simulation  Language 

ECS*  Executive/Control /Subordinate  System 

ED  Engineering  Department 

EUROTOS  European  Tactical  Operations  System 

FDTE  Force  Development  Test  and  Evaluation 

FEBA  Forward  Edge  of  the  Battle  Area 

FIST  First  Intelligence  Simulation  Test 

FORSCOM  US  Army  Forces  Command 

FSED  Full  Scale  Engineering  Development 


GAO 

GS 


General  Accounting  Office 
General  Support 


HEL 

HFE 

HFEA 

HRD 

HRDT 

HSC 

ICTP 

IEP 

JP 

IPCE 

IPS 

ISD 

ITDT 

JGD 

LOOM 

LCSMM 

LEA 

LOA 

LSA 

LSAR 

M 

MAP 

MASSTER 

MENS 

MIOD 

MILPERCEN 

MIRAT 

MMM 

MOS 

MROC 

MRSA 

MTBF 

MTI 

MTP 

NBC 

NET 


US  Army  Human  Engineering  Laboratory 
Human  Factors  Engineering 
Human  Factors  Engineering  Analysis 
Human  Resources  Data 
Human  Resources  in  Design  Trade-Offs 
US  Army  Health  Systems  Command 
Individual  and  Collective  Training  Plan 
Independent  Evaluation  Plan 
Independent  Evaluation  Report 
Interim-Interim 

Independent  Parametric  Cost  Estimate 
Integrated  Personnel  Summary 
Instructional  Systems  Development 
Integrated  Technical  Documentation  and  Training 

Job  Guide  Development 

Logistics  Composite  Model 
Life  Cycel  System  Management  Model 
US  Army  Logistics  Evaluation  Agency 
Letter  of  Agreement 
Logistic  Support  Analysis 
Logistic  Support  Analysis  Record 

Maintainability 
Manpower  Analysis  Plan 

Modern  Army  Selected  Systems  Test,  Evaluation,  and 
Review 

Mission  Element  Need  Statement 

Message  Input/Output  Device 

US  Army  Military  Personnel  Center 

MILPERCEN  Initial  Recruit  and  Training 

Maintenance  Manpower  Modeling 

Military  Occupational  Skill 

US  Army  Medical  Research  and  Development  Command 

US  Army  Materiel  Readiness  Support  Activity 

Mean-T i me-Be  tween-Fa i 1 ure 

Moving  Target  Indicator 

Manufacturing  Methods  and  Technology  Program 

Nuclear,  Biological,  and  Chemical 
New  Equipment  Training 


OAP 

OFPP 

OMB 

OPM 

OSD 

OSUT 

OT 

OTEA 

OTP 

0T4E 

O&O 


PEP 

PM 

PMO 

PT/ME 


QQPRI 


Outline  Acquisition  Plan 
Office  of  Federal  Procurement  Policy 
Office  of  Management  and  Budget 
Office  of  the  Project  Manager 
Office  of  the  Secretary  of  Defense 
One  Station  Unit  Training 
Operational  Test 

US  Army  Operational  Test  and  Evaluation  Agency 
Outline  Test  Plan 
Operational  Test  and  Evaluation 
Organizational  and  Operations! 


Producabil Ity  Engineering  and  Planning 

Project  Manager 

Project  Management  Office 

Physical  Tea rdown /Maintenance  Evaluation 


Qualitative  and  Quantitative  Personnel  Requirements 
Information 


R  Reliability 

RFP  Request  for  Proposals 

ROC  Required  Operational  Capability 

RTO  Radio  Telephone  Operator 


SAG 

SAI 

SAT 

SATOS 

SES 

SIGINT 

SIMTOS 

SOC 

SOTAS 

SOW 

SPA 

SPC 

SQI 

ss 

SSG 

STF 

STO 


Study  Advisory  Group 
Science  Applications,  Inc. 

Systems  Analysis  of  Training 

Seventh  Army  Tactical  Operations  System 

Systems  Engineering  Study 

Signal  Intelligence 

Simulated  Tactical  Operations  System 

System  Ownership  Cost 

Stand-Off  Target  Acquisition  System 

Statement  of  Work 

Skill  Performance  Aids 

Systems  Planning  Corporation 

Special  Qualification  Index 

System  Safety 

Special  Study  Group 

Special  Task  Force 

Search  and  Track  Operator 


TAC  CP 
TACFIRE 


Tactical  Comnand  Post 
Tactical  Fire  Control  System 


TACOM 

US  Army  Tank-Automotive  Command 

TASA 

Task  and  Skill  Analysis 

TCS 

Tactical  Computer  System 

TCT 

Tactical  Computer  Terminal 

TOP 

Test  Design  Plan 

TOR 

Training  Device  Requirement 

TM 

Technical  Manual 

TOA 

Trade-Off  Analysis 

TOD 

Trade-Off  Decision 

TOE 

Table  of  Organization  and  Equipment 

TOS. 

Tactical  Operations  System 

TOS* 

Tactical  Operations  System  Operable  Segment 

TP 

Test  Plan 

TRADE 

Training  Devices 

TRADOC 

US  Army  Training  and  Doctrine  Command 

TSM 

TRADOC  System  Manager 

TSS 

Target  Surveillance  Supervisor 

TSP 

Training  Support  Package 

TSWG 

Training  and  Support  Working  Group 

T4E 

Test  and  Evaluation 

U-COFT 

Unit  Conduct  of  Fire  Trainer 

UIOD 

User  Input/Output  Device 

USAEUR 

US  Army,  Europe 

USD (RE) 

Under  Secretary  of  Defense  (Research  and  Engineering) 

UTM 

Universal  Transverse  Mercator 

VCSA 


Vice  Chief  of  Staff,  Army 


